Flags --otp and --persistent don't play nice together

[smktpd]

Flag --otp is for specifying time-based one-time password, I make a sub-shell call $() to retrieve it from keepassxc.
Flag --persistent attempts to re-connect if tunnel failed. But it looks like the attempts to reconnect using old totp.

Connection log looks like this

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
...
INFO:   Tunnel is up and running.
INFO:   Cancelling threads...
INFO:   Cleanup, joining threads...
INFO:   Setting ppp0 interface down.
INFO:   Restoring routes...
delete host ${pub_ip_of_vpn_server}: gateway 192.168.88.1
${date} : Hangup (SIGHUP)
${date} : Modem hangup
${date} : Connection terminated.
${date} : LCP close (User request).
${date} : Connect time 24.1 minutes.
${date} : Sent 435481 bytes, received 5043662 bytes.
ERROR:  pppd: The link was terminated by the modem hanging up.
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
INFO:   Logged out.
INFO:   Connected to gateway.
ERROR:  Could not authenticate to gateway. Please check the password, client certificate, etc.
INFO:   Closed connection to gateway.
INFO:   Logged out.
INFO:   Connected to gateway.
ERROR:  Could not authenticate to gateway. Please check the password, client certificate, etc.

A possible solution would be to remake --otp flag (or introduce a new one) so that it would expect not the totp code itself, but a command that should yield one.

I'm on ARM-based device with macos Sonoma 14.6 (23G80) running openfortivpn installed from brew, tried versions 1.20.5 and 1.22.1 (latest available).

[dligthart]

Yes, I'm experiencing the same issue.

[yossizahn]

I have made a very simple code change to fix this issue in #1258

All it does is clear the OTP from the configuration for subsequent connection attempts.

@smktpd

A possible solution would be to remake --otp flag (or introduce a new one) so that it would expect not the totp code itself, but a command that should yield one.

This already exists in a sense, by configuring --pinetry= in the command line or config file. You will need to somehow get keepassxc cli to speak the pinentry protocol (see here for an example for 1password)

[smktpd]

I have made a very simple code change to fix this issue in #1258

I don't understand how that is supposed to be helpful.
A connection (even a subsequent one) needs an OTP, so what would you achieve by clearing it?

This already exists in a sense, by configuring --pinetry= in the command line or config file.

--pinentry option exists, but it is used to supply password, not OTP, as per its description.

see here for an example for 1password

That instruction is confusing and raises many questions, but I think the main issue with it is that it is probably not applicable to openfortivpn.

[yossizahn]

I don't understand how that is supposed to be helpful.

By clearing the OTP after the first connection attempt, openfortivpn will revert to prompting for the user for the OTP in subsequent connection attempts.
Together with the pinentry option and a wrapper script to keepassxc cli, you can automatically supply a new OTP every time you get prompted.
Without the change, openfortivpn attempts to connect with the old OTP and fails.

--pinentry option exists, but it is used to supply password, not OTP, as per its description.

Did you test? It is used for prompting for the OTP too
See image

That instruction is confusing and raises many questions, but I think the main issue with it is that it is probably not applicable to openfortivpn

I don't see why you think so. pinentry uses a simple IPC protocol to get the password from the pinetry program.
Any command may be adapted to "speak" that protocol by a similar wrapper script to the one I linked.

[yossizahn]

@smktpd This article may clear things up about pinentry
https://velvetcache.org/2023/03/26/a-peek-inside-pinentry/

[smktpd]

Thanks for your replies. I've read the article, some things are a bit clearer now, but only in general, without details.

Now I feel like I'm bit of in a pickle, as... I don't want to manually provide neither password, nor OTP, I want it to get retrieved fully automatically.

On MacOS there's a built-in CLI tool security which can be configured to be used without prompts to access data stored in a so called 'keychain' (which can be manually managed via built-in 'Keychain access' app).

Since this keychain can't be used to store OTPs directly (in a sense that the new values should be generated based on time of access) - one indeed has to resort to the use of 3rd party password stores (like '1password' that you suggested or like KeePassXC that I use) for storing OTPs and may configure keychain to have password for said password stores to retrieve OTPs from there without prompts.

This way I've successfully automated VPN connection without prompts, so the only issue here is the inability to re-connect.

And it looks like pinentry-mac might be a third wheel in this equation and adding it to the chain of programs needed to be executed to retrieve the OTP to be passed to openfortivpn - might not bring any benefits, as it seems, and it isn't trivial how to build that chain.

Also, pinentry seems to be originally made for GPG keys and googling solutions returns a lot of results assuming GPG key is what you want to unlock via password passed to pinentry and KeePassXC in particular doesn't seem to support working as a pinentry for GPG as per this ticket: keepassxreboot/keepassxc#3519

In other words, your solution might be more useful to others, who want to write-in OTP codes manually, but for people like me - it's better to add support of a $() sub-shell call for --otp that'd be re-executed every time if --persistent was enabled.