This is a howto guide for establishing an IPSec VPN tunnel to an Amazon Virtual Private Cloud (VPC) using the pfSense 2.0 (RC1) open source router / firewall distribution. We will use Border Gateway Protocol (BGPv4) inside the tunnel, between the inside IP addresses, to exchange routes from the VPC to the example network using the OpenBGPD software package (available in the pfsense distribution as an add-on package).
In this tutorial, we will be using the following example network topology for demonstration purposes (be sure to change the the RFC1918 WAN address space we show as 172.16.0.80/28 to your actual WAN, as well as the other LAN and AWS subnets to match your requirements):
Please be sure to make a backup of your entire pfSense configuration before proceeding, in the case you need restore a sane configuration.
Step #1: Deploy an Amazon VPC
Comprehensive instructions on setting up a Virtual Private Cloud on Amazon AWS can be found on the Getting Started Guide.
Although we will not cover all of the steps required for launching an Amazon VPC, you must choose an available external IP address on your pfSense gateway during the setup process. In this example, we are using 172.16.0.81 from our /28 WAN subnet.
In the setup process, you must define your internal address space for your VPC subnet, which will be associated with your VPC instances. After configuring the tunnel (presuming you have set this up using the AWS management Console), navigate to VPN Connection, highlight the connection you created, and select Download Configuration, choosing the generic vendor-agnostic configuration options.
You should also at this point create an instance in your new VPC and assign it an IP address within the VPC subnet you have defined, so at a later time you will be able to perform networking tests from hosts inside your pfSense VPN.
Another important step in this process is to ensure that there aren’t any blocking features set in the Security Group that has been associated with your VPC instance. The Networking ACLs, out of the box, are setup to Allow ALL.
We will over the other relevant settings required on the AWS side for networking later in this tutorial.
Step #2: Install Required Software
The next phase in our setup is to install the BGP daemon software from within the pfSense web UI. Navigate to System > Packages and install the OpenBGPD software. We will come back later to actually configure this software.
Step #3: Configure the Virtual IP Address Space on pfSense
We will need to create an IP alias of 169.254.255.2/30 for our Inside Address, so that we can communicate with our Amazon BGP peer (neighbor) at 169.254.255.1.
In the pfSense web UI, navigate to Firewall > Virtual IP’s, and select the plus button to add a new item. match the following configuration as shown in the image below and save:
Step #4: Create a New Gateway and Static Route
The next step in the process is to configure a gateway on the pfSense WAN. This will be used for our static route to in communicating with our AWS BGP peer.
In the pfSense web UI, navigate to System > Routing, which will bring you to the Gateways tab. Set the following parameters as shown in the image below, adjusting the values for your particular deployment:
After creating the new gateway and applying the changes, select the Routes tab, and replicate the following settings as shown below:
pfSense will now be able to properly route the BGP traffic through our predefined Customer Gateway in our IPSec tunnel.
Step #5: Configure the pfSense IPSec VPN
We will now setup our IPSec VPN. From the pfSense web UI, navigate to VPN > IPSec, and select the plus button to create a new phase 1 entry. Copy the following settings shown below:
Save and apply these settings, and make sure to leave the tunnel disabled for now.
Create a new phase 2 entry by selecting the button as shown below:
This will reveal the list of associated phase 2 tunnels (currently empty). Select the plus button to create a new phase 2 entry as shown in the image below:
Setup this tunnel with the local and remote subnets like so, ensuring that it is enabled before saving:
We will now create a second tunnel (repeating the process above), but this time declaring the local LAN subnet behind our pfSense router in the Local Subnet field, and the VPC subnet we wish to connect to:
Step #6: Configure OpenBGPD
Our configuration process is now ready for setting up our BGP daemon. Navigate to Services > OpenBGPD and configure the Settings tab as follows:
Next, setup a BGP group under the Group tab as shown below (make sure you reference the parameters provided in the VPC configuration you downloaded earlier):
Now we need to navigate to the Neighbors tab, and setup the parameters for our VPC peer:
We are almost there…
Step #7: Setup IPSec Interface Firewall Rules
One important step in our initial setup phase is to create a rule on the IPSec interface in the Firewall > Rules dialog on the pfSense router. Ensure that you initial are allowing bidirectional traffic for all protocols on the IPSec interface.
Step #8: Finalize Settings and Enable IPSec VPN
One of our last steps before we enable our VPN is to browse back to the AWS Management Console and edit our VPC Route Tables.
To finalize our routes, we must setup:
- Destination: <pfSense LAN Subnet> | Target: vgw-acbd1234
- Destination: <VPC Subnet> | Target: local
- Destination: <0.0.0.0/0> | Target: igw-abcd1234
Please verify that all of the above have the Status of active before proceeding.
The remainder of this guide will focus on bringing up our connections, and will aim to give you the tools and dialogs needed to troubleshoot any potential issues.
Navigate back to VPN > IPSec from the pfSense web UI, and edit the IPSec phase 1 VPN you created. Uncheck Disable this phase 1 entry, then Save and Apply Changes.
At this point pfSense will enable the IPSec VPN.
You should now navigate to Status > IPSec in a new browser tab to monitor the status, Security Associations and logs. It may take some time for the connection to establish, depending on your pfSense system resources and network latencies, so have a bit of patience for the VPN to fully initialize.
When the two green icons appear under the Status menu (Status > IPSec > Overview), this will confirm that the VPN is up. Be sure to check the pfSense system logs if these both do not appear within a few minutes time.
Open another browser tab and navigate in the pfSense web UI to Services > OpenBGPD > Status. Here we are looking for a couple of things.
First we should look and see if we have established communications by viewing the OpenBGPD Summary section, and taking note of the Up/Down column. We can also view the system logs, under Status > System Logs where we should see the bgpd process log valid next hops.
Second, we you will want to check the OpenBGPD IP section to confirm that OpenBGPD is seeing the routes announced from the VPC (in this case, you should see 0.0.0.0/0 on one line AND your VPC subnet listed).
The OpenBGPD Neighbors section at this point should also be populated with statistics.
Test Networking to a VPC Running Instance
Presuming your pfSense deployment has been set to allow all traffic on the IPSec interface (and your LAN interface is set to allow egress ICMP traffic and SSH/TCP 22), from a host within your pfSense LAN, traceroute to the instance in the VPC. You should see something close to the following output:
traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 60 byte packets
1 10.1.1.1 (10.1.1.1) 0.296 ms 0.293 ms 0.285 ms
2 169.254.255.1 (169.254.255.1) 83.361 ms 87.950 ms 88.896 ms
3 169.254.255.13 (169.254.255.13) 89.247 ms 88.994 ms 89.426 ms
4 192.168.1.2 (192.168.1.2) 89.242 ms 89.083 ms 89.387 ms
If this stops at the 169.254.255.13 hop, you should verify that you have the correct settings in your VPC Route Table, as covered in the beginning section of this step. If the above traceroute succeeds, proceed with logging into the instance via SSH. Once logged in, you should perform the reverse networking tests from the instance to hosts in your pfSense LAN.
Once confirmation of bidirectional networking has been established, you should proceed with tightening down your security settings for allowing the minimums access controls needed.
Feel free to contact me with any questions or recommendations for revisions to this article.