Link to home
Start Free TrialLog in
Avatar of Tore Jacobsen
Tore JacobsenFlag for Norway

asked on

Allways-on VPN acting strange..

Hi and thanks for reading.
We have always-on VPN sat up in our Network.
Some users complain that they can only connect to local recourses for a very short time. After that it shows as connected on Win 10 pc, but no traffic can go over until they disconnect and connect again.
If we test by running a continuous ping it stays up. Until we stop ping. and then VPN tunnel close after 5 sec... (but still shows as connected)

During testing, we also found that connecting over hotspot (via iPhone) it works fine.
Also some users repport they have no problems. So ISP is a factor. But strange that as they can connect and that as long as a ping is running the tunnel is up!!

Please help
Avatar of noci
noci

You don't mention the VPN technology...  OpenVPN, IPSEC, wireguard, other....

IPSEC f.e. will only show a tunnel as "Down" when it explicitely is torn down...
Closing down 5 seconds after last packet is strange...   far too short.

NAT can be a problem esp. when combined with UDP. Even then a timeout between 30 - 120 seconds minimum should be expected for it.
(more often 120 sec. than 30 sec).
Check logs for messages. Also you could try to find if there is any traffic by dumping network packet using f.e. wireshark.
Avatar of Tore Jacobsen

ASKER

Thank you for your comment.

Yes this is using IPSEC (with IKEv2).

If i run wireshark i can still see NAT-Keepalive msages going to the VPN server eventhough the tunnel is down (nor really sure what i should look for).
I can no longer see the device under "Remote Client Status" list in "Remote Access Management Console", but the Windows 10 Client still say Connected on the VPN.
If i manually click disconnect and reconnect it will be up for a few seconds again.

If i start a continues ping to an internal server over the VPN, then the connection will hold.

IKE should still keep using port  500/UDP.  (needs to fly regularly...)


IPSEC can go across several protocols.  ESP (protocol 50) or Using port 4500/UDP.

ESP cannot handle NAT very well due to the IP addresses being part of the hash in the packet in many cases,

you may need to enable NAT support, which will enforce use of port 4500 for the tunnel packets.

(Those should be flying across as well).


The windows client probably has no functional DPD (Dead Peer Detection), or no keep alive support.

NAT is not relevant if the tunnel endpoint is terminated on the PUBLIC address on both sides.


The ping can be a solution if the keep alive isn't done for port 4500 packets.

This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.