VPN strange behaviour

Showing results for 
Show  only  | Search instead for 
Did you mean: 

VPN strange behaviour

L4 Transporter


I have  configured a VPN between JUNIPER SSG550 and PA-3020 (5.0.5) but this VPN is not going up. Yesterday I was configuring this VPN almost 4 hours until finally vpn went up Smiley Happy but i checked this morning the vpn state and its down again and nobody has changed the config ...weird.... I have checked the VPN config and i have created the VPN again and the VPN is not going up now Smiley Sad

====> Initiated SA:[500]-[500] cookie:39e59d4fd22fc29a:0000000000000000 <====


====> Failed SA:[500]-[500] cookie:39e59d4fd22fc29a:0000000000000000 <==== Due to timeout.

2014-03-07 12:40:33 [INFO]: ====> PHASE-1 SA DELETED <====

====> Deleted SA:[500]-[500] cookie:39e59d4fd22fc29a:0000000000000000 <====

2014-03-07 12:40:36 [INFO]: IPsec-SA request for queued since no phase1 found


====> Initiated SA:[500]-[500] cookie:2fa8ed99f184af97:0000000000000000 <====


====> Failed SA:[500]-[500] cookie:2fa8ed99f184af97:0000000000000000 <==== Due to timeout.

2014-03-07 12:41:28 [INFO]: ====> PHASE-1 SA DELETED <====

I have similiar VPN configured between this juniper and PA and its working with the same config.......

it seems like phase1 is up but i cant see the green light in NETWORK-IPSEC TUNNELS

Any advice?????


L7 Applicator

Hello COS,

From the above mentioned logs, it's looking like IPSec phase-1 started as an initiator, but the second packet didn't receive by the PAN firewall. Out of total 6 messages for PHASE-1 ( main mode), the 2nd message should be received from the responder with" responder cookies".

The PAN firewall will wait for a particular time for that  " message-2 with responder cookie", if not, then it will delete the Security-Association keys (SA).

Hence there could be multiple reason behind this failure:

1. Could you please verify if both firewalls are having an untrust-to-untrust security policy to allow IKE.

2. Verify if the same packet has been received by the Juniper-FW also and tried sending Message-2.

3. Run below mentioned CLI command:

>show vpn ipsec-sa tunnel <tunnel name>

> show vpn ike-sa gateway

> clear vpn ike-sa gateway XXXXX

Delete IKEv1 IKE SA: Total 1 gateways found.

> clear vpn ipsec-sa tunnel XXXXXX

Delete IKEv1 IPSec SA: Total 1 tunnels found.

> test vpn ike-sa gateway XXXXXX

Initiate IKE SA: Total 1 gateways found. 1 ike sa found.

> test vpn ipsec-sa tunnel XXXXXX

Initiate IPSec SA: Total 1 tunnels found. 1 ipsec sa found.

> show vpn flow

>show vpn flow tunnel-id x  << where x=id number from above display

Reference doc: IPSec Error: IKE Phase-1 Negotiation is Failed as Initiator, Main Mode. Due to Negotiation Timeout

CLI Commands to Status, Clear, Restore, and Monitor an IPSEC VPN Tunnel

Please let us know the result.


L6 Presenter

There are many reasons for the message "due to timeout"

Be sure nothing changed on both sides after tunnel was up

Also disable tunnel monitoring on SSG side.

Yes both firewalls are allowing IKE between peers.........

Its weird becasue if i do "test vpn ike-sa gateway XXXX"

i cant see the parapmether in phase1 "MAIN MoDe, 3des,sha1......"

OK ill continue on monday....ill give you news.....thanks a lot

Yes, im sure nothing was changed.....i think the VPN was up and becaouse of lifetime the  VPN was live for 8 hours and then died......

i have enabled vpn monitor in both sides, disabled vpn monitor, enable NAT-T, disable NAT-T, with proxy-ID, without proxy-ID......i dont know what more i can try

ill change to ANY ANY the policies between peers just in case.....

illl give u news on monday thanks a lot for ur help Smiley Happy


====> Initiated SA:[500]-[500] cookie:2fa8ed99f184af97:0000000000000000 <====

This could be for following reasons:

1. PAN device is sending out UDP 500 packet to start phase 1. But it is not received on SSG side.

2. SSG received PAN UDP 500 packet, but is not sending out 2nd message with responder cookie.

3. SSG received PAN UDP 500 packet and sent 2nd message with responder cookie. But it is not reaching PAN device.

4. SSG sent 2nd message and PAN device received it. But did not recognize it for some reason.

Best thing to do in this case is to narrow down which side is having a problem. I would suggest running packet captures on both PAN side as well as SSG side filtering for UDP 500 packets. What you are looking for is to see if PAN is sending IKE packet and on SSG side make sure IKE is received. If PAN side shows IKE is sent but SSG side never sees the packet, then you have an issue on your provider side possibly blocking UDP port 500.

Just remember for any VPN troubleshooting you always want to look at both sides of the tunnel. So let us know what SSG is seeing as well.



I just checked and i have seen in MONITOR->SESSION BROWSER that we had a session ike and ipsec frozen, i deleted this session and the VPN its up NOW.....

why VPN session was stuck???? what reasons can be do this????

thanks a lot


I´ve also seen such frozen ike and ipsec sessions sometimes, but only with older PANOS version (most of the time 4.1.x versions). No obvious reason for this issue...you can open a TAC case, but this is imo only helpful if you are able to run several cli commands (show session id .... for the frozen session, show vpn ....,  tech-support-file) while the session is in this frozen state.

However there is no obvious bug-ID in the current release notes 5.0.11 regarding this particular behavior I would suggest an update to one of the latest 5.0.x versions (5.0.10 is at this time very stable in my opinion).

Best regards,


L2 Linker

Is an upgrade to PANOS 5.0.11 possible? At least for the PA-VM this upgrade  was recommended by the TAC in my case. I run ScreenOS 6.3.0R14 currently on my Netscreen side.

I use vpn-monitor on the ScreenOS side.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!