AWS IPSec Tunnel success?

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L4 Transporter

AWS IPSec Tunnel success?

Hello folks,

 

I am so close to a successful AWS IPSec tunnel to my on premise (test) PA200 7.1.15.

 

I've downloaded the configuration file and using it as a guide, IPs, etc.

But I've been using this article to configure.  Main difference is I created a specific AWS zone like I do for all my IPSec Tunnels.  

http://www.richardyau.com/?p=240

 

I am able to access my on premise environment from the AWS EC2 instance, but not from on premise to AWS EC2 172.31.24.69.

I can't ping it or connect to the EC2 via RDP.  I see the ping tries in traffic log, but nothing shows up in packet trace for the RDP attempts.  <UPDATE>  Resolved after correcting IPs for PBF and RDP connection from LAN.

 

AWS has two VPN connections for redundancy.  I have both configured and active.

NOTE:  My Azure IPSec tunnel works great!

paaws1.jpg

 

Configured tunnel interfaces according to AWS text document.

paaws2.jpg

 

Configured tunnel monitor profile.

paaws3.jpg

 

Configured PBF like referenced in documentation. <Corrected>

 

awscorrection1.jpg

Configured Static routes for both VPN connections (different metric).

paaws5.jpg

 

Created security rules in and out for AWS zone, open.

paaws6.jpg

 

No additional NAT rules.  Just basic outbound internet rule to Untrust.  <corrected>

awscorrection2.jpg

A ping from a VM inside my LAN ages out.  Nothing shows up when I try to RDP, including a packet trace, not even a drop file.

paaws8.jpg

 


Accepted Solutions
Highlighted
L4 Transporter

I've resolved this, able to communicate to AWS EC2 back and forth.  I've corrected my screenshots above.

My configuration errors:

- PBF destination IPs were incorrect.

- NAT rule not needed.

- Was using incorrect IP when attempting to RDP from LAN resource.  That's why was not showing up in my log.

- Ping was not working because was not enabled on AWS security group.

View solution in original post


All Replies
Highlighted
L4 Transporter

I've resolved this, able to communicate to AWS EC2 back and forth.  I've corrected my screenshots above.

My configuration errors:

- PBF destination IPs were incorrect.

- NAT rule not needed.

- Was using incorrect IP when attempting to RDP from LAN resource.  That's why was not showing up in my log.

- Ping was not working because was not enabled on AWS security group.

View solution in original post

Highlighted
L1 Bithead

Does the inbound from AWS to On-Prem(resource) work ?

 

Are you using multiple-vr's ?

sjk
Highlighted
L4 Transporter

Sorry for my delayed response.  Yes, I did get AWS to On-Premise working.  I did not create a separate or second Virtual Router.  Just used my default.  Please let me know if I can help or provide more notes.  I still have this running...

Highlighted
L2 Linker

Hi OMatlock

 

We have a similar issue from or end, for some reason we can't enable both tunnels at the same time- as it creates asymmetric routing. For e.g if traffic is sent from one tunnel, the PAN will reject any traffic from the other tunnel.

I see you have configured both tunnel interfaces to be part of the same zone. But we have used different zone, not sure if this is an issue too?

 

- we had to enable ECMP- later knew its not supported by AWS

 

Kind Regards

Anu

Highlighted
L4 Transporter

If you are refering to both tunnels going to the same VPG on the same firewall, yes, leave them in the same zone.  While they do not support ECMP, they also do not guarantee the same tunnel will be active always.  Putting the tunnels in the same zone will overcome IP Spoofing issue that creates.

Highlighted
L2 Linker

Thanks for the suggestion

we will try that option as well. Also AWS suggested the below

 

Entering configuration mode [edit] # set deviceconfig setting tcp asymmetric-path bypass

# set deviceconfig setting session tcp-reject-non-syn no

# commit

 

We are quite hesitant to enable this gloabally, as this would also apply for non aws traffic. So enabled this via the zone protection profile - strickly for that zone.

 

 

Highlighted
L4 Transporter

I agree with your hesitation.  In general, routing asymmetry is bad for security visilbility.  I would not turn off reject no sync on your internet facing interfaces.  

Highlighted
L2 Linker

thanks Jmeurer. I will try re-try this by moving to the same zone. Do you know or come across any step by step guide to the setting up process between the tunnels between on-prem palo and aws VPC's.

 

Kind regards

Anu

L4 Transporter

I typically recommend to start with this guide.

https://github.com/PaloAltoNetworks/aws-transit-vpc/blob/master/documentation/Transit_VPC_Manual_Bui...

 

Once you have your Transit Firewalls built, you can terminate the on-prem Firewalls on the Transit Firwalls with VPNs as if they are another spoke.  From there you can control policy locally or with Panorama, creating rules based on zones or subnets.

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 Live Community as a whole!

The Live Community thanks you for your participation!