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: 192.168.0.0/24
AWS Oregon VPC Network: 172.31.0.0/16 (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, 18.104.22.168/16)
- 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 172.31.0.0/16 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 192.168.0.0/24 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 (172.31.0.0/16) to go through the tunnels we created, so we will add two static routes on our Untrust Router (172.31.0.0/16) 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 (192.168.0.0/24) addresses. We will SSH connect to our EC2 instance from a computer that is on our internal network (192.168.0.0/24) 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 (192.168.0.0/24) to verify connectivity.
[[email protected] ~]# ssh -i SecretKey.pem [email protected] The authenticity of host '172.31.8.158 (172.31.8.158)' 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 '172.31.8.158' (RSA) to the list of known hosts. Last login: Wed Dec 24 21:56:31 2014 from 209-x-x-x.my.domain.net [[email protected] ~]$ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=68.0 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=69.2 ms ^C --- 192.168.0.1 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