Detecting VPN Disconnections sooner for retry

[sai3563]

Hello,

I started using openfortivpn recently to do some script based automation that I can't do via FortiClient GUI.

I am using this within WSL2.

I have setup a script such that if openfortivpn disconnects, it will keep retrying 5 times after which the script stops.

One scenario where this would be useful is when the system wakes up from sleep. On waking up, VPNs are usually in the disconnected state and need to be reconnected.

But the problem I'm facing is, openfortivpn takes upto 2 minutes to detect this and then reconnect.

Until then, it's just stuck like this

INFO:   Tunnel is up and running.
DEBUG:  pppd ---> gateway (59 bytes)
DEBUG:  pppd ---> gateway (59 bytes)
DEBUG:  pppd ---> gateway (10 bytes)
DEBUG:  pppd ---> gateway (54 bytes)
DEBUG:  pppd ---> gateway (10 bytes)
DEBUG:  pppd ---> gateway (95 bytes)
DEBUG:  pppd ---> gateway (10 bytes)
DEBUG:  pppd ---> gateway (10 bytes)
DEBUG:  pppd ---> gateway (95 bytes)
No response to 4 echo-requests
Serial link appears to be disconnected.
Connect time 2.5 minutes.
Sent 9648 bytes, received 10010 bytes.
DEBUG:  pppd ---> gateway (25 bytes)
DEBUG:  pppd ---> gateway (25 bytes)
Connection terminated.
Modem hangup

I kept getting messages like DEBUG: pppd ---> gateway (10 bytes) for 2 minutes after waking the system from sleep, even though the VPN at this point was clearly disconnected. (Tested by checking public IP address.) Only then I received the further messages. So I was wondering, is there a way to make openfortivpn detect it sooner like within 10 seconds? 2 minutes is too long and I would just have to resort to manual restart instead of waiting that long.

[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.