Remote user gets disconnected-no reply from the gw on tunnel test packet

[flachance]

We have a user who keeps getting disconnected from remote VPN several times a day.

What I see in the helpdesk.log is entries like these:

[13 Mar 10:48:45] No reply from the gw ip=x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18002.

[13 Mar 10:48:47] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18003.

[13 Mar 10:48:49] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18004.

[13 Mar 10:48:51] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18005.

[13 Mar 10:48:54] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18006.

[13 Mar 10:49:17] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18008.

[13 Mar 10:49:20] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18009.

[13 Mar 10:49:22] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18010.

[13 Mar 10:49:24] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18011.

[13 Mar 10:49:26] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18012.

[13 Mar 10:49:29] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18013.

[13 Mar 10:49:31] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18014.

[13 Mar 10:49:33] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18015.

[13 Mar 10:49:36] No reply from the gw ip= x.x.x.x for tunnel test packet. Office Mode IP=10.20.9.65, source port=18016.

[13 Mar 10:49:36] IKE tunnel disconnected, error code=-1000. Reason: Site is not responding.

[13 Mar 10:49:36] Client state is connected

[13 Mar 10:49:36] Tunnel (2) disconnected. State is connected. Trying to reconnect.

[13 Mar 10:49:36] Client state is reconnecting

[13 Mar 10:49:36] Reconnect finished successfully (2)

Is there any additional places/logs I can look for indications of why it is happening? Any recommended settings that could potentially help with this?

Client is E86.20. Gateway is R80.40 JHF take 192

Thanks

[the_rock]

Hey @flachance 

Some basic things I would try:

1) See if you can update one or 2 clients to latest EP version (E87.20) and test

2) Run packet capture on the firewall -> fw monitor -e "accept port(18234);"  (thats UDP port 18234, for tunnel test)

3) If you know approximate time when this occurs, also run following on the fw -> fw ctl zdebug + drop | grep "18234" (that would tell us if anything is dropped on tunnel test port)

4) Does this happen to everyone or only some folks?

5) When did it start?

Also, this is what TAC asked us to do when customer had this issue couple of years back (it got fixed by upgrading the cluster). Dont ask me what this option does, as no one could tell us, though it did not seem to make slightest difference (its in global properties)

This is an explanation for it:

Back connections

Usually communication with remote clients must be initialized by the clients. However, once a client has opened a connection, the hosts behind VPN can open a return or back connection to the client. For a back connection, the client's details must be maintained on all the devices between the client and the gateway, and on the gateway itself. Determine whether the back connection is enabled, and the frequency of the Keep Alive packets sent by the client in order to maintain the connection with the gateway.

Hope that helps mate.

Cheers,

Andy

[flachance]

1-So I tried to upgrade the client to the latest recommended version (E86.80). It actually made things worst it fails connecting most of the time. Users has to retry 4 to 5 times before connecting successfully. We're gonna go back to 86.20 for now.

2-Once we're back to 86.20, I'll try some capture

3-It happens at random times unfortunately

4-No only some folks. And I can actually only find one for whom it's happening all the time. Apparently there are others but I can't get details from them. The user I'm focusing on to troubleshoot has cable internet we did a spedd test and got 63 Mbps down and 10Mbps up.

5-Started a few months ago. The only thing that changed near that period (that I'm aware of) is the following: We've been asked to increase the VPN re-authenticate time from 1 day to 5 days. Could this consume more resources and create this type of issue? Why only for some users?

thanks for your help and suggestions

[the_rock]

Im little surprised newer client made things worse, as in my experience, installing newest client version would usually help. 

Anywho, can you run the capture I mentioned in my first response? Also, what is authentication setting changed to 5 days you are referring to? Honestly, I learned long time ago that changing any sort of timeout for those things is pretty much useless (for the lack of better word), because if you think about it logically, all thats going to do is take LONGER for things to fail, but it wont change the behavior, it will still fail at the end of the day.

Andy

[flachance]

Yes, I'll start another thread with the client upgrade issue. I don't think they're related but possibly upgrading the client could help with the disconnect issue.

This is the re-authenticate time that was changed (I'm not sure it's related but who knows). 

I'll look at the capture next.

[the_rock]

Ah, that setting, no, that wont do a single thing here. All that does is prompts user to re-enter their password again, so they can stay connected to VPN.

[flachance]

Yes. I was wondering if staying connected longer could maybe use more resources and cause issues but I don't think it's related.

[the_rock]

Trust me, 100% its not related, I can guarantee you that.

[checkingout]

i am having the same issue. the clients get disconnected because it could not get a response from the fw. checking the firewall logs, it shows that it is not sending the tunnel test response because "Violated unidirectional connection".  any idea why? 

i have tried @the_rock  suggestion to enable "back connections" back it didnt seem to work. 

also, my checkpoint firewall is behind a NAT device.

[the_rock]

Im not shocked that setting did not do much for you, because even TAC could not confirm exactly what it does, apart from copying/pasting exactly what it says in the help section, but to me, its still not clear : - ). Anyway, are you seeing any traffic on port 18234 (tunnel test packets)? Do you have a log of the error mentioned?

[Homer]

Have you got found a solution for the problem? 

[flachance]

We never did find what was going on. One of those annoying issue that goes away after a while for which you don't exactly know what happened or changed.

[Homer]

Many thanks for the answer! I've been struggling with this error for several months.
The latest patches are already installed. That's why I'm still looking for a solution.

[NiladriSarkar]

I was experiencing the same issue and found that anti spoofing was blocking traffic between mgmt ip and office mode ip. Note: we have mdps enabled.