How to Create an IPSec Tunnel to AWS (Amazon Web Services) From a Palo Alto Firewall with Static Routing

In this tutorial, we will create two redundant IPSec tunnels connecting our internal network to Amazon Web Services so we can access our cloud instances over a private network.

In this example we will use the following address scheme:

Toronto Office Internal Network:
AWS Oregon VPC Network: (Class B)


  • Static IP binded onto Palo Alto Firewall
  • VPC Private Network created with a CIDR block where you would like to connect. (Our example,
  • IPSec Tunnels are based per region. If you have multiple regions, you will have to create additional redundant tunnels per region.
  • One EC2 instance connected to the VPC to test


1. Create A Customer Gateway

  • Log into AWS, and go to Networking > VPC
  • Under VPN Connections > Customer Gateways create a Customer Gateway and label your external site identifier, enter in your Palo Alto firewall IP address and specify outing as Static



2. Create a Virtual Private Gateway

  • Go to VPN Connections > Virtual Private Gateways and create a Virtual Private Gateway for your network exit point for your region.



  • Attach the VPC to this gateway



 3. Create VPN Connection

  • Give the connection a name, and assign it the Virtual Private Gateway and Customer Gateway from previous steps
  • Specify the routing as Static and enter in your internal network CIDR block so AWS VPC would know which subnets to route to your internal network
  • Note: Once you click “Yes, Create” AWS will start billing you for IPSec connections



  • Add Static Route to your internal network if you do not see it



 4. Download Configuration

  • Right Click on the VPN Connection that you created and select “Download Configuration”
  • Select Palo Alto Networks, PA Series and PANOS 4.1.2+
  • This file will include VPN settings and secret keys you have to apply on your Palo Alto firewall.


5. Follow the AWS Configuration Guide That Was Created in Step 4

  • Since encryption keys and crypto types have to match exactly on both ends, make sure you follow the guide that was downloaded in step 4. I will be referencing the guide that was generated in the next couple steps.

5a) Create IPSec Tunnel #1

  • Create an IKE Crypto Profile by going to Network > Network Profiles > IKE Crypto and use the settings as stated in the guide




  • Add and create the first IKE Gateway by going into Network > IKE Gateway and using the settings stated in the guide





  • Create the AWS IPSec Crypto by adding a profile in Network > Network Profiles > IPSec Crypto




  • Create a Tunnel Interface in Network > Interfaces > Tunnel
  • For our setup, we will put the tunnel interface in our Untrust Zone and in the Outside Virtual Router





  • Create an IPSec Tunnel under Network > IPSec Tunnels with the settings you created




  • Add a Tunnel Monitor profile under Network > Monitor so it will monitor the tunnel in case it detects a failure



  • Create a Policy Based Forwarding Rule to remove the Static Route for the tunnel if a failure is detected




 5b) Create IPSec Tunnel #2 for Failover

  • Create 2nd IKE Gateway in Network > Network Profiles > IKE Gateway




  • Create 2nd Tunnel Interface



  • Create 2nd IPSec Tunnels in Network > IPSec Tunnels




  • Create 2nd Policy Based Forwarding Rule for 2nd Tunnel in Policies > Policy Based Forwarding



6. Add Static Route to Palo Alto Virtual Router

  • For our Firewall Setup, we have two basic zones. A Trust zone and an Untrust zone. Our Trust zone is our internal subnet and the Untrust zone is everything outside the subnet
  • The default route of our Trust zone goes through to the Untrust Zone
  • We have placed the VPN tunnels in the Untrust Zone
  • We would like all AWS traffic ( to go through the tunnels we created, so we will add two static routes on our Untrust Router ( to go through the tunnel interfaces



  • Make sure the 2nd route has a higher metric to differentiate the routes



7. Create Security Policy to Allow inbound VPN Traffic on the Palo Alto Firewall

  • Add the following Security Policy to allow IPSec Inbound traffic. Make sure it goes above any overshadowing rules.



  • Save and Commit
  • Don’t worry about the Policy Based Forwarding Overshadow notice when committing. If you would like to not see this, remove the PBF rule you added that has a higher metric you set in the above step.

8. Start Up IPSec Tunnels

  • Log into the CLI of the Palo Alto Firewall and issue the following commands to start the tunnels you created
[email protected]> test vpn ike-sa gateway AWS-Ike-Gateway1
Initiate IKE SA: Total 1 gateways found. 1 ike sa found.

[email protected]> test vpn ike-sa gateway AWS-IKE-Gateway2
Initiate IKE SA: Total 1 gateways found. 1 ike sa found.

[email protected]> test vpn ipsec-sa tunnel AWS-Oregon-Tunnel-1
Initiate IPSec SA: Total 1 tunnels found. 1 ipsec sa found.

[email protected]> test vpn ipsec-sa tunnel AWS-Oregon-Tunnel-2
Initiate IPSec SA: Total 1 tunnels found. 1 ipsec sa found.


 8. Check to See If Tunnels are Up

  • Go to Network > IPSec Tunnels and the two tunnels that you’ve created are both green. If they are not, check Monitor > System and see if there are any errors


  • Check AWS to see if your tunnels are up under VPN Connections > VPN Connections > Tunnel Details



9. Add Your Internal Network to your VPC Route Table

  • To make your Internal network routable from your VPC, add your internal CDR block to your VPC route table and specify your AWS Virtual Private Gateway



  • Associate all VPC subnets to this route


10. Create an Outbound NAT on the Palo Alto Firewall to NAT AWS Tunnel Addresses to your Internal Network Gateway Address

  • In our example, there is a default Trust to Untrust traffic NAT set for our firewall external IP. We need to create a NAT above that rule specifying that all AWS interal traffic NATs to our internal gateway address instead. Save and commit


11. Create EC2 Instance and Test

  • Create an EC2 Instance with an IP Address on your VPC Network
  • When adding the security group, make sure you allow proper access for your internal subnet



  • For our EC2 instance we allowed SSH inbound from our internal IP ( addresses. We will SSH connect to our EC2 instance from a computer that is on our internal network ( and authenticate with our saved AWS keypair.
  • Once we can log in to our EC2 instance, we can do a secondary test by pinging any available host in our internal subnet ( to verify connectivity.
[[email protected] ~]# ssh -i SecretKey.pem [email protected]
The authenticity of host ' (' can't be established.
RSA key fingerprint is 12:4b:73:ae:1c:b6:5d:93:91:32:9d:4e:53:08:b1:83.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
Last login: Wed Dec 24 21:56:31 2014 from

[[email protected] ~]$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=63 time=68.0 ms
64 bytes from icmp_seq=2 ttl=63 time=69.2 ms
--- ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2002ms
rtt min/avg/max/mdev = 68.097/68.671/69.246/0.631 ms




Leave a Comment