pulse connect 5.1 frequent disconnect

[nskarim]

Hi,

I am looking into an issue with pulse connect client 5.1 disconnecting while connecting to the SSL VPN running 8.1R4.1
I have seen the following error on on the SSL VPN whenever the client disconnect " Transport mode switched over to SSL for user with NCIP x.x.x.x"

Network Connect - No split tunneling] - Closed connection to x.x.x.x after 667 seconds, with 39417 bytes read and 3348 bytes written
Info NWC23465 2015-11-15 20:30:24 - remoteOSL2 - [y.y.y.y] xxxxxx( RSA)[Full Access - Network Connect - No split tunneling] - VPN Tunneling: Session ended for user with IPv4 address x.x.x.x
Info NWC24328 2015-11-15 20:30:05 - remoteOSL2 - [y.y.y.y] (RSA)[Full Access - Network Connect - No split tunneling] - Transport mode switched over to SSL for user with NCIP x.x.x.x
Info NWC23508 2015-11-15 20:19:22 - remoteOSL2 - [y.y.y.y] (RSA)[Full Access - Network Connect - No split tunneling] - Key Exchange number 1 occurred for user with NCIP x.x.x.x

My understanding is that the formally ESP tunnel fails after 1 hour and then VPN switch to SSL. This is happening every 1 hour after client connection
Has anyone has an idea on what could be causing this issue?

Cheers

[jbeakley]

When working as designed, the Pulse Secure clients should revert from ESP to SSL only if the ESP (UDP) connection fails consistently. More specifically, there are timeout/heartbeat mechanisms that ensure that UDP packets are being transmitted properly; if this mechanism indicates a failure for more than 75 seconds, then the tunnel will revert from ESP to SSL.

So, the first step would be to see whether there is anything in the networking substrate that might cause the blockage of UDP packets after an hour. Perhaps a network-node change, like a firewall or router? There have been cases in the past of customers incorrectly configuring load-balancing or other clusters of Pulse gateways, and this can cause packet loss. You may need to consult your system administrator to see whether these apply to you.

If the network substrate can be ruled out as a cause, then you may want to contact Pulse Secure's Global Support Center for more information:

http://www.pulsesecure.net/support

If you do, you may want to reference ticket PRS-324375.