cancel
Showing results for 
Search instead for 
Did you mean: 

Junos Pulse dead time after connection

SOLVED
Highlighted
Occasional Contributor

Junos Pulse dead time after connection

Hi All,

 

I am runnning a pair of MAG 2600 in A/A and noticed a weird problem when I started using Junos Pulse instead of Network Connect.

 

When I connect with Junos Pulse my connection seems to be dead for a good 20 or so seconds then it starts to work.  I attached the ping results to show the ammount of time it takes before the connection begins to work.

 

C:\Documents and Settings\XPMUser>ping 172.29.100.50 -t  Pinging 172.29.100.50 with 32 bytes of data:  Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Reply from 172.29.100.50: bytes=32 time=7ms TTL=124 Reply from 172.29.100.50: bytes=32 time=3ms TTL=124 Reply from 172.29.100.50: bytes=32 time=3ms TTL=124 Reply from 172.29.100.50: bytes=32 time=9ms TTL=124 Reply from 172.29.100.50: bytes=32 time=14ms TTL=124

 

 

I should note that If I use network connect I have no issues and traffic starts passing right away.

 

Also I can see that on the upstream switch there is no ARP present for my host station until the pings start working.

 

Anybody have any ideas what could be causing this?

 

Details:  

-  MAG 2600 7.3R8

- Users dropped into a specific tagged USER vlan connected to a Juniper EX switch.

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Valued Contributor

Re: Junos Pulse dead time after connection

I've seen this issue when the pulse is having issues connecting via esp or there is a delay enabling the virtual adapter. Review the debug log and confirm when tunnel manager is enabled. It will se 'enable tm interface'. If this corresponds to the same time ping start responding, the logs will need to be review why there is a delay. Most likely, it is a esp failover issue. Pulse will attempt to connect via esp first for 15 seconds, then fail over to ssl. There should be a 'esp keep alive failed' in the logs which confirms the issue

View solution in original post

3 REPLIES 3
Highlighted
Frequent Contributor

Re: Junos Pulse dead time after connection

Have you read through this to see if it applies?

http://kb.pulsesecure.net/InfoCenter/index?cmid=no&page=content&id=KB25855



Highlighted
Occasional Contributor

Re: Junos Pulse dead time after connection

Kita is correct.  This is exactly what is happening.  I have my connection going through an F5 Loadbalancer that is only allowing 443.  When Pulse starts it tries to establish via ESP first which timeouts then defaults to SSL.

Stupid mistake on my part but hopefully this post will help someone in the future.

Highlighted
Valued Contributor

Re: Junos Pulse dead time after connection

I've seen this issue when the pulse is having issues connecting via esp or there is a delay enabling the virtual adapter. Review the debug log and confirm when tunnel manager is enabled. It will se 'enable tm interface'. If this corresponds to the same time ping start responding, the logs will need to be review why there is a delay. Most likely, it is a esp failover issue. Pulse will attempt to connect via esp first for 15 seconds, then fail over to ssl. There should be a 'esp keep alive failed' in the logs which confirms the issue

View solution in original post