Forum Discussion
NimbostratusSSL VPN Disconnect Issue
We currently have an issue with our SSL VPN connection disconnecting on random intervals. I do have a open support case and unfortunately not making any drastic headway, so reaching out here to see if anyone has had this issue or possibly something else I can try. We previously were using Juno Pulse and did not have this issue with any clients.
I am able to re-produce the disconnect by doing a simple file copy from one of our systems to my PC. Below is all the information that shows in the APM log, unfortunately there does not appear to be any further debug with PPP tunnels.
2014-08-15 06:59:05 Assigned PPP IPv4: 192.168.0.57 Tunnel Type: VPN_TUNNELTYPE_TLS NA Resource: /Common/VPN 2014-08-15 06:59:05 PPP tunnel 0x57025106e400 started. 2014-08-15 07:10:07 PPP tunnel 0x57025106e400 closed.
Next we went to wireshark where we are seeing a lot of TCP zero window packets, so I set the zero-window-timeout to infinite to rule out zero window disconnects. The issue still occurs after making this change.
Currently I am working on a client side capture to compare with the tcpdump on the appliance, but I am not seeing anything in the capture that stands out as a red flag (I am no wireshare expert by any means so digging though these captures is pretty slow).
Any thoughts or information is greatly appreciated, also please let me know of other info that would be of use.
Check the DNS settings of the F5 and make sure it can resolve the sslvpn fqdn.
Background: We had similar issues, the PPP tunnel kept randomly closing and opening a new one, which caused the clients to reconnect, which in turn caused traffic not flowing while the PPP tunnel did a new handshake.
There were no evidence in the LTM log why this happens, but the Edge client log revealed that DNS lookup for the APM endpoint (LTM VIP) didn't resolve. The client machine actually could resolve it, but the F5 itself couldn't. After changing the DNS servers in F5 to ones that resolved correctly the problem seems to have been solved.
walou12_113339Hi, Are you running full tunnels or split tunnels?. We had a similar problem with split tunnels, some clients would disconnect after 10 min. Logged a support call and did a lot of debugging, it appeared to be triggered by some route change event on the client. but we never got to the bottom of it and went back to full tunnel.
Rusty_M_140798We are using split tunnels, I will try testing without today to see if the issue still happens. But split tunneling is a big requirement as we are using MS Lync and running SSL over SSL has some pretty large performance issues.- Rusty_M_140798Also, I found this setting as well "Prohibit routing table changes during Network Access connection" When enabled, routes in the client routing table for the F5 PPP adapter cannot be added, deleted, or modified. Any request to add, delete, or modify a route pointing to the F5 PPP adapter is discarded. Did you try this setting or did it have any effect?
- Rusty_M_140798Tested both, unfortunately nether of the above changes made a difference.
In which direction do you get the Zero Windows? Setting the timeout to zero can have other unexpected behaviour.
The log shows an almost 10min timeout for your disconnection. Have you gone through the Access Policy settings to see whether there is anywhere a disconnect is being set? (this is typically in the first option page of the Access Policy)
- Rusty_M_140798Sorry for the delay in my response, we are seeing the Zero Window on the client side capture. Currently we have the setting set to the default of 2000 since changing it did not yield any results. Everything on the access policy is default, the log attached is just one example sometimes its 10 min another time its 30 min then its 2 hours. No real time variable available.
Grayson_149410Did you ever find a fix for this? We just went through a Firepass to APM changeover. For some people it works great, but we are finding a lot of people are getting disconnected at the five minute mark. We have a VS listening on 443 and then another Forwarding VS that is used to route their connections down a different path. We set the Client Profile Protocol to a custom Fast Level 4 with Idle Timeout set to indefinite so that applications handle that, but still seems to be affecting people.
- Rusty_M_140798So commenting on a old problem late, short answer is no we have not found a solution to this. I still have a case open and the issue still exists on 11.6 HF4. Some users never have a problem and others have it constantly, we have even gone as far as re-installing the OS. Currently we are packet capturing for development support. For your issue if it is 5 minutes on the dot then I would say it is a timeout issue. Search though the protocols and see if there is anything that is set to 5 min or 300 seconds.
- chaouqui_14878
Matti_63169Check the DNS settings of the F5 and make sure it can resolve the sslvpn fqdn.
Background: We had similar issues, the PPP tunnel kept randomly closing and opening a new one, which caused the clients to reconnect, which in turn caused traffic not flowing while the PPP tunnel did a new handshake.
There were no evidence in the LTM log why this happens, but the Edge client log revealed that DNS lookup for the APM endpoint (LTM VIP) didn't resolve. The client machine actually could resolve it, but the F5 itself couldn't. After changing the DNS servers in F5 to ones that resolved correctly the problem seems to have been solved.
Johnny__Xie_269Hello Matti, We had similar issue. May I know where you find the DNS lookup failure on BIG IP box? Where the DNS servers change you have done to resolve it? Thanks in advance!
MattiCheck the DNS settings of the F5 and make sure it can resolve the sslvpn fqdn.
Background: We had similar issues, the PPP tunnel kept randomly closing and opening a new one, which caused the clients to reconnect, which in turn caused traffic not flowing while the PPP tunnel did a new handshake.
There were no evidence in the LTM log why this happens, but the Edge client log revealed that DNS lookup for the APM endpoint (LTM VIP) didn't resolve. The client machine actually could resolve it, but the F5 itself couldn't. After changing the DNS servers in F5 to ones that resolved correctly the problem seems to have been solved.
- Johnny__Xie_269Hello Matti, We had similar issue. May I know where you find the DNS lookup failure on BIG IP box? Where the DNS servers change you have done to resolve it? Thanks in advance!
Minn_62043Cirrostratus
Does logterminal.txt shows anything for the disconnected session?
You may need to increase the client-side log levels. Please refer to this:
https://support.f5.com/kb/en-us/solutions/public/12000/600/sol12639.html- Francisco_Abel_
Hi all,
Another possibility which I observed in the past regarding the following scenario: - Split tunneling enabled - ProxyPAC enabled with corporate URL for PAC file - Let's suppose than both the DNS and the hostname for the mentioned URL are routed thru the VPN
In case that, after establishing the VPN connection, the Edge Client cannot download the PAC file from the configured URL, the connection closes prematurely.
At the moment you fix the connectivity problem to the PAC URL, the VPN connection establishes successfully and the problem dissapears.
Francisco
- ICHU_369248
Hi Guys,
Any Fix on this issue i am facing this issue for some clients..
