04-15-2017 06:26 PM - edited 04-15-2017 08:04 PM
The partner company requires that I translate all packets to them so they appear to come from one public IP address. In monitoring on the PAN I can see that the packet passes and the source address is translated. The problem is that the tunnel is not coming up. I've been using the article at the bottom to try and figure things out.
If I run > test vpn ike-sa gateway <name> - the IKE portion comes up on both side - we both see that.
But no traffic can appear to get from one side to the other and the IPSecSA does not come up.
But tryng to get the tunnel up just by simulating some traffic from one of the sites in the local encryp domain is failing:
2017-04-15 19:13:25 [INFO]: IPsec-SA request for 6.6.2.20 queued since no phase1 found
====> Initiated SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:0000000000000000 <====
====> Established SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:37eaf345dc0b7e26 lifetime 28800 Sec <====
====> Initiated SA: 8.8.236.54[500]-6.6.2.20[500] message id:0x83A79855 <====
====> Expired SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:37eaf345dc0b7e26 <====
====> Expired SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:37eaf345dc0b7e26 <====
====> Expired SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:37eaf345dc0b7e26 <====
====> Failed SA: 8.8.236.54[500]-6.6.2.20[500] message id:0x83A79855 <==== Due to negotiation timeout.
====> Expired SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:37eaf345dc0b7e26 <====
====> Deleted SA: 8.8.236.54[500]-6.6.2.20[500] cookie:2800de12dd714ac5:37eaf345dc0b7e26 <====
And debug
19:33:11.536704 IP 6.6.2.20.500 > 8.8.236.54.500: isakmp: phase 1 R ident
19:33:11.541671 IP 8.8.236.54.500 > 6.6.2.20.500: isakmp: phase 1 I ident
19:33:11.595754 IP 6.6.2.20.500 > 8.8.236.54.500: isakmp: phase 1 R ident
19:33:11.600478 IP 8.8.236.54.500 > 6.6.2.20.500: isakmp: phase 1 I ident
19:33:11.654048 IP 6.6.2.20.500 > 8.8.236.54.500: isakmp: phase 1 R ident
19:33:11.659052 IP 8.8.236.54.500 > 6.6.2.20.500: isakmp: phase 2/others I oakley-quick
19:33:11.659248 IP 6.6.2.20.500 > 8.8.236.54.500: isakmp: phase 2/others R inf
19:33:11.713226 IP 6.6.2.20.500 > 8.8.236.54.500: isakmp: phase 2/others R inf
19:33:11.713572 IP 6.6.2.20.500 > 8.8.236.54.500: isakmp: phase 2/others R inf
sho vpn flows seems to show everything stuck in init
142 IPSEC-Hooli-VPN:Hooli-1init off 8.8.236.54 6.6.2.20 tunnel.19
143 IPSEC-Hooli-VPN:Hooli-2init off 8.8.236.54 6.6.2.20 tunnel.19
144 IPSEC-Hooli-VPN:Hooli-3init off 8.8.236.54 6.6.2.20 tunnel.19
145 IPSEC-Hooli-VPN:Hooli-4init off 8.8.236.54 6.6.2.20 tunnel.19
Any other thoughts about how to see why the tunnel is not getting triggered although the security and nat policiy are working?
04-16-2017 08:17 PM
Palo Alto uses route based VPN. So it uses routing table to decide where to send packets to.
If you are setting up VPN with Peer that uses Policy based VPN then encryption domain is used at their side what traffic should be sent into tunnel.
As config has to match at both ends Palo uses ProxyID inside IPSec config to match encryption domain.
So first thing is to check if you have ProxyID configured (Network > IPSec Tunnels > Name of tunnel).
04-17-2017 05:51 AM
as @Raido_Rattameister has mentioned already PROXY-ID is a very common issue for the Phase 2 failure.
Do you know which firewall on the other end?
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!
