LINUX WIFI/Hotspot Connection Issue - SSL-VPN

[michaelITSupport]

Hi Everyone, 

We have an issue with our Forticlient SSL-VPN on LINUX (multiple flavours, redhat, centOS and Oracle) when connected to any standard WIFI, the VPN connection stops receiving packets for some time generally around 40secs to 2mins, then packets start to come through again. After about 2 or 3 time after dropping or delaying the receive packets it just disconnects from the VPN, I am saying delayed as I have a ping setup to a workstation which doesn't drop pings, the time just spans out to 10000ms for about 10-20pings then returns to normal after the packets start coming through again.

So same machines connected to a mobile hotspot using the same WIFI adapter, connected to the same VPN with the same config and they connect perfectly, no drop-outs/dropped packets or delays in receiving packets. Works as it should

LINUX Version 8
Forticlient VPN - 7.0.0.0018
SSL-VPN with no client cert

Split tunnel Connection

Anyone else having a similar issue, there aren't too many settings that we can change. We have checked network settings and they are similar, all of our user and test machines have the same issue when connecting from home WIFI networks as well as other corporate WIFI's. 

I am lost as to where to go, happens straight off a brand new LINUX build too.


Thanks
Michael

[bpozdena_FTNT]

Hi Michael,

based on how the issue is described, it sounds more like wifi related problem.

You should probably ensure that there is no packet loss between the clients and Fortigate - SSL VPN is very sensitive to it.

You can simply test by pinging the SSL VPN gateway. Or even better, by taking a simultaneous packet capture on the client's wlan adapter and on Fortigate. Look for TCP re-transmissions or any other anomalies. 

Boris

[iskandar_lie]

Hi Michael,

do you use split-tunnel? If yes. So whenever the you are connected to vpn - you will get route injection for internal subnet - that you wish to access from ssl-vpn. You can check if the route is there on your client station whenever it disconnects and check the internet connection as well. 

I think this method also will be able to isolate the problem. 

You can try on SSL-VPN portal menu from fortigate to active this (attached) .  

Let us see if this works for you. 

Cheers,

Lie

  

[michaelITSupport]

this setting "Allow client to keep connections alive" is currently off, I am finding out why we would have it off. Although this doesn't make any sense as connecting to a mobile hotspot with the same WIFI adapter works find.

[michaelITSupport]

Hi, 

I have updated my original post with some added information, yes we are using split tunneling the connection (or network) settings are updated on successful connection to the VPN, either normal WIFI connection or a mobile hotspot. The DNS updates with our internal DNS servers although turned off, routing is blank, turned on and set to Auto. The one thing I did miss out on mentioning is when connected to a normal WIFI the split tunneling doesn't work, there is no internet connectivity, however internal connectivity is patchy/delayed at best. The only difference is the hardware we are connect to, we have tried other routers, other mobile devices and TELCO's, where only the hotspots allow full functionality that Windows and MAC uses all currently have on our VPN

Michael.

[depill]

For me after making myself insane about this issue, it seems when the DHCP server DNS server is set to an DNS server on the same subnet. When I either do a static DNS server outside of the subnet in network manager or change the dns server outside of the subnet, it seems to connect and keep connected.

[michaelITSupport]

I think you are on the money with the DNS, I had tried adding in 8.8.8.8 although this didn't work. I think I have found a way, which I am testing...  Will get back to you

[michaelITSupport]

Tried this and didn't seem to work however did work for fedora LINUX... At least its a start

systemctl disable systemd-resolved.service
systemctl stop systemd-resolved
ln -s /var/run/NetworkManager/resolv.conf

Back to the drawing board.

[depill · Accepted solution]

Did you change DNS in Network manager or in resolv.conf. For me when tracking what fortinet Client is doing its queying nmcli directly about the DNS server and seems to fail if it overlaps.

And for me also seems to fail if my local subnet overlaps any of the subnets on the remote.

Bit annoying, but with an extra WiFi i can make it fór at home

[michaelITSupport]

Hey Depill, 

Local subnet was our issue, changed the network to 172.0.0.0/24 and was able to connect, tunnel splitting was fine, access to network was fine, and connectivity was perfect...  It makes more sense now why they mobile network was working as it wasn't in the same subnet. There was a change in subnetting on our system about a month ago and something was reset and not checked. So basic IT 101 solution, at least we are at the bottom of it now....

Thanks everyone for the assistance... Hopefully anyone else can find the solution quicker now that we have some details on here....lol...