Site-to-Site VPN from a Palo Alto Firewall in the AWS.

[nson2139]

Folks,

We have provisioned a Palo Alto Firewall in one of the AWS VPC. This is essentially a single legged deployment and the function of this firewall will only be to act as a transit firewall.

This firewall will have VPN connectivity to the corporate firewall and to some other remote VPC's. Traffic filtering will be done on this Palo Alto Firewall.

The issue we are facing is that we do not see any VPN getting negotiated from this Palo Alto Firewall to either the remote VPC or to the corporate firewall. The Palo Alto firewall has a RFC1918 IP address on it's Eth1/1 interface and then this IP address has been allocated a Elastic IP on the AWS console. At present we are going step-by-step and looking at the errors on the Phase-1 IKE connections.

Our corporate firewall which is a Juniper does get the Phase-1 messages from this Palo Alto firewall but throws out an error saying "Rejected an IKE packet on ethernetx/y from a.b.c.d:500 to e.f.g.h:500 with cookies ********* and 00000000 because an initial Phase 1 packet arrived from an unrecognized peer gateway.

a.b.c.d is the Elastic IP provided in AWS

e.f.g.h is the Public interface IP of the Juniper firewall.

Could someone throw some light on what could be the issue? Is there some way to work on this?

Thanks!!!

[jperry1]

I'm not sure about Junipers but on our devices when you see "00000000" in the log for your peer that means it doesn't recognize it or have a way to route back to it. It amost looks as if something is NAT'ing out for your firewalls untrust interface. Can you ensure that your PAN firewalls Untrust interface is reachable via internet? easiest way to do that would be to add a management profile to your Untrust interface for ping. If you can successfully do this be sure you have provided the correct IP addresses. 

[Warby]

Also, make sure the Juniper isn't configured for peer identification based on the IP address of the VM-Series because the VM-Series is configured with a private IP on the firewall but the packets arrive on the Juniper with a source IP of the IEP.  When those don't match, peer identification fails.  Instead, use something like FQDN or and email address as the peer identificaiton.

[nson2139]

Thanks, in this case the Juniper also behaves the same. That is why for some reason I believe the ID that the PAN is taking to the Juniper may be incorrect.

Yes, the PAN interface is reachable over the Internet using the EIP assigned by AWS.

We can ping/HTTPS to the EIP using the allowed IP range.

Do you know if the EIP assigned on the AWS needs some different setting? I mean some NAT policy or something?

Thanks for the response and suggestions on this.

[nson2139]

We did not specifically configured the Juniper for any peer identification. The logs shows that the assinged EIP is reaching the Juniper so that should be correct.

The other challenge here is we would need to build VPN tunnels from this PAN to other VPC's as well so all configuration would need to reside on the PAN itself.

We did try by adding peer ID/local ID on the PAN but nothing seems to work. 😞

[jperry1]

what type of error does the IKEMGR log show on the PAN firewall? you can see that by running 

less mp-log ikemgr.log or something of that effect. 

Also out of curiosity check the ENI that is used for the VPN termination point on the VM series and see if Source Destination checks is turned on. If so as a test turn that off. 

[nson2139]

It just shows failed due to timeout

 ====> PHASE-1 NEGOTIATION STARTED AS INITIATOR, MAIN MODE <====
                                                      ====> Initiated SA: a.b.c.d[500]-1.1.1.1[500] cookie:916a1f78c71fbe00:0000000000000000 <====

Failed SA: a.b.c.d[500]-1.1.1.1[500] cookie:916a1f78c71fbe00:0000000000000000 <==== Due to timeout.
2018-01-23 22:02:17.000 -0800  [INFO]: {    4:     }: ====> PHASE-1 SA DELETED <====

Here the a.b.c.d is the private IP of the PAN Untrust interface and 1.1.1.1(changed) is the Juniper end IP.

The Source/Destination checks have been turned off as per the guidance from the documents.

[jperry1]

We should never see the private IP address is Phase 1 as this is where the peers are authenticated. If the Juniper doesn't have a routable public IP address then you need to be in aggressive mode on the PAN VM-Series for your VPN setup. At this point I wouldn't deem this an issue with VM series firewall itself. My suggestions here are

1. Figure out why your Juniper Private IP is being sent to the PAN VM-Series firewall

2. If the Juniper doesn't have a static IP address then configure the VM-Series in Aggressive Mode. 

[nson2139]

The above log I took was from the PAN device. This is the one which is showing the Private IP.

The PAN is the initiator and it starts the VPN tunnel with it's private IP.

Now, technically this IP should be NATTted by the AWS and the EIP should be forwarded to the Juniper.

The Juniper does show the EIP in it's logs. 🙂

Is there a way to configure the PAN to send the EIP itself in the logs it sends to the Juniper?

[jperry1]

I misunderstood the private IP being from the PAN so that log is correct. If the public IP addresses are correct then it may go back to what Warby said in the previous post about an identifier. You may need to try a peer identifier. This link is just to illustrate the peer identifier setup.
https://live.paloaltonetworks.com/t5/Configuration-Articles/IPSec-VPN-Tunnel-with-Peer-Having-Dynami...

[nson2139]

yes, all these options have been tried out with no success so far. We are still hunting the options here if there is something very basic that we missed.

[nson2139]

BTW....I did not mention this. The VPC(which hosts the firewall) has 2 VPN's one to route the management subnet directly to the corporate and the second to route the Untrust interface to the corporate for actual data flow...

would that cause any harm?

Should I try to delete the management VPN and then give this a try?

[nson2139]

one more point, we tried a debug on the Juniper end and it shows a message as below:

"Not found: 1st peer_ent that is used, with no peer IP, and right local IP."

by any chance could it be that some tweak needed on the PAN end to ensure that it sends the peer IP?

[jperry1]

If you see the routable Public IP addresses on both devices that are terminating the Phase 1 IKE tunnel that is expected. 

Your logs that show the private IP is expected as well because prior to egress the IP address isn't transalated. 

If you are sure that both the Juniper and PAN have a publically routable IP address and it's not working then the next step would be to open a support ticket and probably with both vendors. I've seen nothing in this thread that tells me either the PAN or the Juniper is the culprit so a support ticket with both vendors would be the way to go depending on the software you are running. 

If you are running a GA release of PAN-OS then you can definitely open a support ticket with PAN support as well. 

[Rashid.pm]

Please check below points you had configured in paloalto properly,

1)NAT-travesal should enable.

2)In security policy ,you need to create policy from untrust to untrust, in case you have any-any deny rule.

3)Try to create a identification, local IP identification and you have to put the outside interface private ip(not the public ip)

Regards

Rashid