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]

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...