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

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

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

L3 Networker


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?






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. 

It just shows failed due to timeout


                                                      ====> Initiated SA: a.b.c.d[500]-[500] cookie:916a1f78c71fbe00:0000000000000000 <====


Failed SA: a.b.c.d[500]-[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 is the Juniper end IP.



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

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. 

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?

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