Detecting VPN Disconnections sooner for retry about openfortivpn

[DimitriPapadopoulos]

When openfortivpn wakes up, it expects to find everything in the state it previously was, which of course won't work and will result in openfortivpn attempting to communicate with the FortiGate until the timeout.

In order to handle that gracefully, openfortivpn would need to be notified of the event. Not sure how programs are notified — probably by systemd on systemd-based Linux distributions. I expect frameworks out there to provide some level of abstraction, but most likely only for Gnome or KDE software.

[sai3563]

@DimitriPapadopoulos Thanks for the reply.

Actually I was researching for a few more hours after posting this and finally found a solution.

The problem was due to the default values of lcp-echo-interval & lcp-echo-failure being quite high, causing openfortivpn to take around 2 minutes to detect VPN disconnection after PC wakes up, delaying reconnection.

I did the following:

sudo vim /etc/ppp/peers/vpnoptions

Text content

lcp-echo-interval 2
lcp-echo-failure 2
noauth

Then, while calling openfortivpn

sudo openfortivpn $vpn_server:$vpn_port --username=$vpn_username --pppd-call=vpnoptions

With this, openfortivpn detects VPN disconnection in 4 seconds rather than 2 minutes.

Since, after waking up my PC, it takes more than 4 seconds for me to enter the password and my domain connected PC's lockscreen to unlock, by the time I resume working openfortivpn has already reconnected. Problem solved!!! 😃

[DimitriPapadopoulos]

On the other hand, long timeouts have avoided me having to reconnect on networks with occasional outages, even after outages of 30 seconds.

Perhaps it would make more sense to detect the system has woken up and forcibly close the connection.

[sai3563]

The length of the timeout, whether long or short, seems to have a limited impact in the context of an automated reconnection system. While a longer timeout could potentially reduce the frequency of reconnections, the automation of this process means there's minimal manual intervention required either way.

In terms of the applications that rely on the VPN connection, their timeouts are separate from that of openfortivpn. Thus, changes to the VPN's timeout settings appear to have no direct effect on them.

Currently, the system is functioning effectively as it is. I generally prefer to keep things straightforward and efficient, avoiding additional complexities unless they are necessary, such as implementing detection mechanisms for system wake-up events.

[DimitriPapadopoulos]

In my case, the length of the timeout is vital, because I am not in the context of an automated reconnection system.

I must use an OTP and my FortiGate does not allow automated reconnections based on the session cookie (auto-connect='off'). Here is the XML configuration sent by the FortiGate:

<?xml version='1.0' encoding='utf-8'?>
<sslvpn-tunnel ver='2' dtls='1' patch='1'>
        <dtls-config heartbeat-interval='10' heartbeat-fail-count='10' heartbeat-idle-timeout='10' client-hello-timeout='10' />
        <tunnel-method value='ppp' />
        <tunnel-method value='tun' />
        <tunnel-method value='websocket' /><auth-ses check-src-ip='1' tun-connect-without-reauth='0' tun-user-ses-timeout='30' />
        <client-config save-password='off' keep-alive='off' auto-connect='off' />
        <exclusive-routing>on</exclusive-routing>
        <ipv4>
                <dns domain='xxxxx.xxx.xx;xxxxx.xxx.xx;xxxxxx.xxx.xx;xxxxxxxxxxx.xxx.xx;xxx.xx' />
                <dns ip='xxx.xxx.xxx.4' />
                <dns ip='xxx.xxx.xxx.3' />
                <assigned-addr ipv4='10.xx.xxx.x' />
        </ipv4>
        <idle-timeout val='1500' />
        <auth-timeout val='36000' />
</sslvpn-tunnel>

Therefore, it is important for me to avoid reconnections.