This is the first in a series of blog posts about gatewaying an office network fronted by PFSense to different cloud vendor's Virtual Private Network(VPN) offerings. Don't miss part two.
The design has two subnets and a VPN connection to a remote office. The first subnet will be a public subnet (192.168.91.0/24), and will be used for hosts that have both public and private IPs assigned to them. The second subnet (192.168.90.0/24) will be used as a backend subnet that will have hosts with only private IP addresses - and no direct external connections. Hosts in the public subnet will be able to reach and be reached from the Internet using an AWS Internet Gateway assuming they've been assigned public IPs. Hosts in the Private Subnet will use a NAT Gateway within the Public Subnet to allow them to reach out to the Internet for software packages and patching. Both the Public Subnet and the Private Subnet will be able to communicate with each other.
Creating the VPC
It's possible to do nearly all the setup in AWS using the VPC Wizard. If you'd like to adapt an existing VPC to this model or better understand what the Wizard is doing, the basic VPC setup follows the steps discussed in Creating a VPC with a Public and Private Subnet.
Using the Wizard
Go to the VPC Dashboard, and select "Start VPC Wizard" which will take you to a screen where you can select the type of VPC you'd like to create. For this design, you should select the "VPC with Public and Private Subnets and Hardware VPN Access" path. This will take you to the dialog box shown below. I've filled it in with the values that would correspond to the architecture described above.
Step 2 - VPC Configuration Options
Setp 3 - Configuring the VPN
Fill in the information in this dialog for your settings. Put your PFSense's WAN IP address in for your Customer Gateway IP. For whatever reason, AWS wont let me have the same IPSec Customer Gateway IP assigned to more than one VPC connection. For PFSense you'll want to select the Static Routing Type. This will bring up the IP Prefix table. Add the internal office network you'll be gatewaying on the PFSense side to AWS and press Create VPC. The wizard will churn and create all the different components to set up the subnets, gateways, routes and so forth.
Public Subnet Configuration
The public subnet will be configured by the wizard as shown in the image below.
The public subnet comes with a igw configured, so anything in it will be able to reach the Internet assuming it has a public IP address assigned. Without a route to the office network, you wont be able to reach the systems in the subnet. Fix this by clicking on the Route Table name just to the right of the Edit button to jump to the Route Table section. Select the Route Table in question, and in the lower pain select the Routes tab. Click "Edit" and then "Add Another Route" to add the route. Enter the office network in the Destination and select your Virtual Private Gateway in the handy drop-down menu in the Target Field as shown in the image below.
Private Subnet Configuration
If you followed the instructions found in Creating a VPC with a Public and Private Subnet to create your VPC you can skip ahead to adding the Virtual Private Gateway route below. Otherwise, we will need to set up the NAT Gateway so the private subnet can get software packages and updates.
Go to the NAT Gateway section and you will create a NAT gateway for the Private Subnet. In the NAT Gateway dialog, you will select the public subnet... I almost always get this backwards when I'm not thinking about it. You want the private subnet to be able to get out, but the NAT gateway has to be in the public one so it has a way out. The machines in the private subnet can reach those in the public one, so it will work. You will also need to associate an EIP with the NAT gateway.
Adding the Virtual Private Gateway route
After creating the NAT Gateway, select the Route Table Selection. Locate the route table that is associated with your Private Subnet. Select this and then in the lower pane, select the Routes Tab. Edit the Routes to add a default route to the NAT Gateway.
Download VPN Configuration Information
Now most of the AWS configuration is complete. Now we will download the information needed to configure PFSense and shift gears over to PFSense. Select the VPN Connections section and then select your VPN Connection.
Click the "Download Configuration" button. and then select PFSense from the Vendor select box and click Download to download the file. This will give you a handy place with nearly all the configuration options you'll need to set.
PFSense IPSEC VPN Configuration
The remainder of this document will cover the configuration of the PFSense firewall to communicate with the VPN endpoint that was configured using the AWS console.
In this phase, the firewalls use the parameters to authenticate each other and set up a secure control channel. In this configuration, this phase uses pre-shared keys for mutual authentication of the VPN peers.
AWS currently only supports IKEv1, so you'll select that in the Key Exchange Version. We will only be tunneling IPv4 so select that fro the Internet Protocol. Our IPSec endpoint is bound to the WAN address. Enter the IP addresses for your AWS VPN endpoint for the Remote Gateway, this can be found in the VPN configuration we downloaded in the step above. Put a description name in for the description, you can also use the value from the downloaded configuration.
The defaults under authentication are what we want, so in this section the only thing you need to do is fill in the Pre-Shared Key you set up when configuring the VPN endpoints above. It can also be found in the downloaded configuration.
The algorithms are where we diverge from the defaults in the downloaded configuration recommendations. Through trial I've attempted to find the most secure selections that both ends support. We will be using AES 256 as the encryption algorithm - which is better than what the downloaded configuration specifies. It is time to move away from SHA1, so we'll pick SHA256 for the Hash Algorithm. For the DH Group we will pick group 24 which offers a modern level of security for our key exchange.
The defaults in the advanced options are ok for our purposes. Click Save and return to the IPSec Tunnels table. Click Add P2 to set up the Phase 2 configuration.
Phase 1 secures the tunnel, in Phase 2 the channel we use to exchange data between networks further secured. IKE Phase 2 uses the keys that were established in Phase 1 of the process and the additional encryption options we will specify below.
Fill in the network endpoint information. For the local network select "LAN Subnet". Remote network type will be "Network" and you'll fill in the AWS subnet you configured. In this example, we'd put in 192.168.90.0/23.
Next we will configure the Phase 2 we configure the additional IPSec encryption options to further secure the data exchange between networks. For protocol we will select ESP so that we are setting up an encrypted channel. We will use AES 256 for the encryption algorithm, and SHA 256 for the Hash algorithm. We select PFS key group 16 as it seems to be the most advanced group supported offering us the most protection as time goes forward.
This section can be left blank.
Click save and you'll be taken back to the IPSec Tunnels Table.
Starting the VPN Connection
Navigate to Status/IPsec to see the IPSec Status table. If your VPN isn't already connected, press the connect button and the status should quickly update to Established.
My connection is actually from a PFSense instance behind a NAT gateway, so you see the NAT IP of the PFSense WAN address an that it is using NAT-T in the image above. You can also see encryption parameters we selected above and that the VPN is up and running.
Similarly, we can expand the SA entries to see the Phase 2 connection information:
Debugging if you run into problems
If you run into problems, the IPSec vpn in pfsense will generate useful logs that should help you figure out why things might not be working. From the Status/IPSec/Overview screen you can select the "Related Logs" button, or just navigate to Status/System Logs/IP Sec. The IPSec process is charon. The Messages should give you some clues into what might not be working.
You'll need to create rules that allow traffic from the IPSec vpn to your network. First, we'll create some aliases in PFSense to make it easier to remember what the ranges are. Navigate to Firewall/Aliases/IP and create a new entry. Configure it as follows:
Similarly, do the same for the private network:
Now, navigate to Firewall/Rules/IPSec section. First we will create a rule to block all access from the public subnet to our internal network. Add a rule to the table and fill in the values as shown below:
If you want machines in your Private AWS range to be able to access systems in the LAN network, you'll have to create rules to allow that. I've allowed SSH in in the example below, but you should adapt it to your needs:
Finally, just to be explicit, I've added a catch all block rule at the end to block all traffic from the IPSec tunnels to the LAN network:
With the end ordering of rules being what is shown below:
In future posts, I'll cover the same thing for both Azure and Google Cloud.