01-22-2018 11:55 PM
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?
01-23-2018 11:52 AM
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.
01-23-2018 01:50 PM - edited 01-23-2018 01:50 PM
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.
01-23-2018 08:48 PM
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.
01-23-2018 08:51 PM
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. 😞
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!