I have written a lot about pfSense and different types of VPN scenarios (AWS, Azure), but never created a post about a site-to-site VPN tunnel with FreeBSD running strongswan and pfSense. The scenario described here works with FreeBSD, but it will work with any other Linux distribution with some small OS dependand changes. The syntax for strongswan is the same, it’s just the configuration file names and locations that are different across distributions. For CentOS, see my other post.

Prerequisites

Both the pfSense box and FreeBSD need to have public IPs. While it’s possible to have them behind NAT, this scenario only covers configurations with public IPs. You should disable the firewall on FreeBSD. Both of pfSense and FreeBSD box need two network interfaces. In my case this is how it looks like.

It’s much easier if you enter these values in a small spreadsheet so you don’t get confused later.

FreeBSD configuration

First, we have to install strongswan, configure the 2nd internal NIC if it’s not configured and allow FreeBSD to act as a gateway for other servers behind it (e.g. servers srv1 and srv2).
Install strongswan from packages.

pkg install strongswan

Edit /etc/rc.conf and add this line, so strongswan starts on boot.

strongswan_enable="YES"

While editing that file, add this line too.

gateway_enable="YES"

…and if your internal NIC is not configured, you can assign the IP there too.

ifconfig_vtnet1="inet 10.39.96.3 netmask 255.255.240.0"

where vtnet1 is the name of the NIC. You can see the name of your NIC by doing ifconfig -a.
Next, we’ll configure strongswan. The config files are under /usr/local/etc. Edit ipsec.conf and delete everything then paste these lines.

config setup
 
conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        authby=secret
        keyexchange=ikev2
        mobike=no
 
conn net-net
        left=140.82.31.124
        leftsubnet=10.39.96.0/20
        leftid=140.82.31.124
        leftfirewall=no
        right=67.81.194.50
        rightsubnet=192.168.1.0/24
        rightid=67.81.194.50
        ike=aes256-sha256-modp2048!
        esp=aes256-sha256!
        auto=start
        lifetime=1h

If you look at lines 13, 14 and 15 you’ll see that line 13 is the external IP of our FreeBSD box, line 14 is the internal subnet for FreeBSD and line 15 is just a description for this connection. In my case I used the IP. The same applies for lines 17, 18 and 19. Line 17 is the external IP of the pfSense, line 18 is the internal subnet for the resources behind pfSense and line 19 is just an ID for this connection.
NOTE: if you change the IDs, e.g. lines 15 and 19, then you have to change the same in the secrets file.
The secrets file is a password that will be used to communicate between FreeBSD and pfSense. Another option is to use certificates and it’s not that difficult to reconfigure that, but that’s not in this scope. So, edit /usr/local/etc/ipsec.secrets and add this line.

140.82.31.124 67.81.194.50 : PSK "supersecretpassword"

Don’t use tabs. Spaces only or it won’t work. As you can see you are specifying the leftid, then the rightid and some password. PSK means pre-shared key or password. The parameter leftid and rightid in ipsec.conf must be the same with the parameters here. So, if I change the line 14 to be leftid=@freebsd, I have to do the same in ipsec.secrets. I have to specify @freebsd instead of 140.82.31.124.

pfSense

Now that the FreeBSD strongswan box is configured, we can configure pfSense. In pfSense, go to VPN | IPSec from the menu and click on Add P1 button. Fill out the General Information section, so it looks like this.

As you can see, we use IKEv2 and our remote gateway is 140.82.31.124 which is the FreeBSD strongswan box.
For Phase 1 Proposal (Authentication and Algorithms), fill out the section so it looks like this. The Pre-Shared Key is what you put in /usr/local/etc/ipsec.secrets file, remember?

Then for Phase 1 Proposal (Algorithms), use these values. If you look at your ipsec.conf, you’ll see how they match.

…and use the defaults for the Advanced Options.

Once you click Save at the bottom, pfSense will bring you back. Just click Apply Changes.
Do the phase 2 now, click on Show Phase 2 Entries and then click Add P2.

For the phase 2, enter the following information. Choose Network instead of LAN and add the subnets for both pfSense and FreeBSD. In my case it looks like this. Phase 2 is very important because you have to make sure you enter the proper values. One extra checkmark and you’ll be endlessly troubleshooting why it’s not working. So, pay attention please!

For the Phase 2 Proposal (SA/Key Exchange) i have AES 256 bit instead of Auto and SHA256 instead of SHA1. Lifetime is also 3600.

And you can leave the Advanced Configuration as is. If you notice that your tunnel drops because there is 0 activity, you can enter the IP address of the FreeBSD box or an IP for a server that’s behind FreeBSD. This will send ping ICMP packets to the destination so it keeps the tunnel alive. It’s not necessary, but you never know. Click Save then Apply Changes again.
By default, pfSense will block the IPsec traffic, so you have to enable it. From the menu go to Firewall | Rules and click on IPSec submenu. Click Add and fill out the form so it looks like this.

…and this.

Click Save and go back to the FreeBSD box. Reboot the FreeBSD.

Site-to-site VPN tunnel

Once FreeBSD comes back up, do:

ipsec status
Security Associations (1 up, 0 connecting):
     net-net[1]: ESTABLISHED 8 seconds ago, 140.82.31.124[140.82.31.124]...67.81.194.50[67.81.194.50]
     net-net{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ca009d9e_i cc8a8b76_o
     net-net{1}:   10.39.96.0/20 === 192.168.1.0/24

…and if you go to pfSense, under Status | IPsec you can see the tunnel established.

If you try to ping the FreeBSD from a server behind your pfSense, you’ll get a response. But if you try to ping something behind pfSense from the FreeBSD box, it won’t work.
Check the routes in FreeBSD.

netstat -nr | grep 192
192.168.1.0/24     140.82.30.1        US       vtnet0

This is a wrong route that strongswan injected. Delete the route and add the proper one.

route delete 192.168.1.0
delete net 192.168.1.0
route add -net 192.168.1.0/24 10.39.96.3
add net 192.168.1.0: gateway 10.39.96.3

Now if you ping something, it will work. But wait! Once we reboot, everything will be messed up again? Correct!
First, add this line in /etc/rc.conf. It creates a permanent static route.

route_vpn="-net 192.168.1.0/24 10.39.96.3"

Second, prevent strongswan to mess up with the routes. Edit /usr/local/etc/strongswan.conf and above line load_modular = yes, add install_routes = no. It looks like this.

......
charon {
        install_routes = no
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
}
......

After this change, restart strongswan.

service strongswan restart

NOTE: For any resource behind FreeBSD, you have to add a static route for the 192.168.1.0/24 network. For example, for Windows type route add 192.168.1.0/24 10.39.96.3 -p otherwise that resource will use the default gateway.

I have written a lot about pfSense and different types of VPN scenarios (AWS, Azure), but never created a post about a site-to-site VPN tunnel with CentOS running strongswan and pfSense. The scenario described here works with CentOS, but it will work with any other Linux of BSD distribution. The syntax for strongswan is the same, it’s just the configuration file names and locations that are different across distributions.

Prerequisites

Both the pfSense box and CentOS need to have public IPs. While it’s possible to have them behind NAT, this scenario only covers configurations with public IPs. You should disable the firewalld on CentOS (initially). Both of them need two network interfaces. In my case this is how it looks like.

It’s also easier if you create a small spreadsheet so you don’t loose track of the IPs and subnets.

CentOS configuration

I am using CentOS 7. First, we have to install strongswan and disable the firewall temporarily.

yum -y install epel-release
yum -y install strongswan
systemctl enable strongswan
systemctl stop firewalld
systemctl disable firewalld

Once installed, change these system variables so you allow IP forwarding and prevent ICMP redirects.

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_redirects=0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.send_redirects=0" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf

strongswan on CentOS places its config under /etc/strongswan directory. We’ll use a config with pre-shared key because it’s easier to implement. So, edit the /etc/strongswan/ipsec.conf file, remove everything there and paste this config. Of course, this assumes that you don’t have any working configs there. Now, look at the highlighted lines. That’s where you have to replace the IPs and the subnets with your values. E.g. line 13 is the private IP of the CentOS server, 14 is the subnet, 15 is the ID of the server (IP or hostname), 17 is the external IP of the pfSense server, 18 is its subnet and line 19 is the ID of the pfSense server (IP or hostname). This is where the small spreadsheet above comes handy.

config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        authby=secret
        keyexchange=ikev2
        mobike=no

conn net-net
        left=148.27.56.195
        leftsubnet=10.1.96.0/20
        leftid=148.27.56.195
        leftfirewall=no
        right=23.183.125.249
        rightsubnet=192.168.1.1/24
        rightid=23.183.125.249
        ike=aes256-sha256-modp2048!
        esp=aes256-sha256!
        pfs=no
        auto=start
        lifetime=1h

Then, edit the /etc/strongswan/ipsec.secret file and specify the pre-shared key. This is a password that the servers will use to authenticate. Make sure it’s something more complex in production. In my case, the password is “secret“.

	
# ipsec.secrets - strongSwan IPsec secrets file
148.27.56.195 23.183.125.249 : PSK "secret"

pfSense

Now that the CentOS strongswan box is configured, we can configure pfSense. In pfSense, go to VPN | IPSec from the menu and click on Add P1 button. Fill out the General Information section, so it looks like this.

As you can see, we use IKEv2 and our remote gateway is 148.27.56.195 which is the CentOS strongswan box.
For Phase 1 Proposal (Authentication and Algorithms), fill out the section so it looks like this.

From the screenshot above, you can see that the values correspond to what we have in ipsec.conf file.
For the Advanced Options section, use the defaults.

Click Save and then from the main IPSec | Tunnels menu, click on Add P2 button.
For Phase 2, fill out these values for the General Information section.

Change the values for Local Network and Remote Network to suit your needs. These are the local subnets behind pfSense and strongswan.
For Phase 2 Proposal (SA/Key Exchange) section, choose these values.

For the Advanced Configuration section, you can leave it as is, or put the private IP of the CentOS box so the IPSec protocol sends keep-alive pings. It’s not mandatory, but if your tunnel fails frequently, you can configure this field.

Click Save and the VPN config is done. But, we have to tell pfSense to allow IPSec traffic. So, from the menu go to Firewall | Rules and click on IPSec submenu. Click Add and fill out the form so it looks like this.

…and this.

Click Save and go back to the CentOS box.

Site-to-site VPN tunnel

At this point you can start the VPN.

systemctl start strongswan

If everything is OK, the log will look like this.

tail -f /var/log/messages
Mar  9 16:15:00 titan charon: 09[NET] sending packet: from 148.27.56.195[500] to 23.183.125.249[500] (256 bytes)
Mar  9 16:15:00 titan charon: 10[NET] received packet: from 23.183.125.249[500] to 148.27.56.195[500] (224 bytes)
Mar  9 16:15:00 titan charon: 10[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr ]
Mar  9 16:15:00 titan charon: 10[IKE] authentication of '23.183.125.249' with pre-shared key successful
Mar  9 16:15:00 titan charon: 10[IKE] IKE_SA net-net[1] established between 148.27.56.195[148.27.56.195]...23.183.125.249[23.183.125.249]
Mar  9 16:15:00 titan charon: 10[IKE] scheduling reauthentication in 3350s
Mar  9 16:15:00 titan charon: 10[IKE] maximum IKE_SA lifetime 3530s
Mar  9 16:15:00 titan charon: 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Mar  9 16:15:00 titan charon: 10[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
Mar  9 16:15:00 titan charon: 10[IKE] CHILD_SA net-net{1} established with SPIs c82fdbae_i ce57b856_o and TS 10.1.96.0/20 === 192.168.1.0/24

Check the status.

strongswan status
Security Associations (1 up, 0 connecting):
     net-net[3]: ESTABLISHED 3 minutes ago, 148.27.56.195[148.27.56.195]...23.183.125.249[23.183.125.249]
     net-net{3}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c818e2d7_i c34c4c3d_o
     net-net{3}:   10.1.96.0/20 === 192.168.1.0/24

If the current CentOS box is not your Internet gateway for the servers behind, you have to add a static route to the pfSense subnet. So, on each server behind CentOS, do something like this.

route add 192.168.1.0 mask 255.255.255.0 10.1.96.3 -p

Check the documentation for other OSes. You have to tell the OS to use 10.1.96.3 (internal strongswan IP) as a gateway to 192.168.1.0 subnet. Because my pfSense box is also my gateway, I don’t have to make these changes.

Firewall

Now, everything is up and running, but we have the firewall disabled and the CentOS box is exposed to Internet. Not good. In order to fix that, we have to make some changes and allow the IPSec protocol to flow through the firewall.

systemctl enable firewalld
systemctl start firewalld
firewall-cmd --set-default-zone=dmz
firewall-cmd --zone=dmz --permanent --add-rich-rule='rule protocol value="esp" accept' 
firewall-cmd --zone=dmz --permanent --add-rich-rule='rule protocol value="ah" accept' 
firewall-cmd --zone=dmz --permanent --add-port=500/udp 
firewall-cmd --zone=dmz --permanent --add-port=4500/udp 
firewall-cmd --permanent --add-service="ipsec"
firewall-cmd --zone=dmz --permanent --add-masquerade
firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 -m policy --pol ipsec --dir out -j ACCEPT
firewall-cmd --reload

…and you are all set.

Lately, I was playing with pfSense trying to access my internal resources from outside (mostly my Plex server) so I made this tutorial on how to access my home network. I’ve used the official howto from pfSense, but it’s a little bit outdated and it doesn’t cover Linux/FreeBSD non-GUI, so there are some changes that I’ve made. I’ll be using IPsec IKEv2 AES256/SHA256/MSChapV2/DH14 on the pfSense side (strongSwan IPsec implementation) and the clients will use various VPN clients.
There are a lot of different versions of VPN IPsec implementation, so even the slightest updates can make the VPN fail. I’ll write the version of the server/client for each configuration, so you’ll know that it works. If you are using different versions of the OS or the client, it might not work. I will use only one pfSense config for all mobile clients. Unfortunately, pfSense does not support multiple mobile clients configs as of 2.4.2.
How this works? Each client will receive a certificate and a username and a password. The certificate is the same for all clients, but the username/password is not.

pfSense 2.4.2

In order for the VPN config to work we’ll need a Certificate Authority (CA) and a server certificate. If you have them already, then you can skip the following three parts, if not, I’ll show you how to create them.

pfSense FQDN

Check your FQDN first under System | General Setup. This is what I have as FQDN and I’ll use this FQDN later in my certificate and in my client’s config.

pfSense CA (Certificate Authority)

From the pfSense menu go to System | Cert. Manager. Click on Add and then you can choose to Import an existing Certificate Authority or Create an internal Certificate Authority. In my home lab I already have an existing CA (see this link on how to create your own CA), but for this post, I’ll create a new CA. Enter a Descriptive Name for the CA and choose to Create an internal Certificate Authority.

Under the Internal Certificate Authority section , fill out the values that suit your home/lab/company. In my case, I used 2048 for Key length (bits) and sha256 for Digest Algorithm. Enter the Lifetime of the CA, I used 3650 days which is 10 years and fill out the rest of the form. Make sure to use your FQDN for the Common Name. For example, my pfSense box has an external IP assigned to the WAN interface which is 1.2.3.4. Also, somewhere in my DNS, I resolve this IP to mysweethome.mysweetdomain.com. You have to put mysweethome.mysweetdomain.com for Common Name.

Click Save when done.

pfSense Server Certificate

From the pfSense menu go to System | Cert. Manager. Click on the Certificates tab and choose Create an internal Certificate.

For the Internal Certificate section, choose the CA that you’ve just created, keep the same Key length and Digest Algorithm and fill out the rest of the form so it looks like this.

Again, for the Common Name choose the DNS name of your pfSense.
For the Certificate Attributes section, choose a Server Certificate, not User Certificate and enter the FQDN domain of your pfSense box, as well as the IP. The IP is not mandatory, but it means that when you create your client config, you can specify the IP of the pfSense, instead of using FQDN.

pfSense IPsec mobile clients config

Once the certificates are in place, go to VPN | IPsec from the menu and then click on Mobile Clients. Enable the IKE Extensions, choose Local Database for User Authentication and none for Group Authentication.

For the Client Configuration section, use the following settings. Check the Virtual Address Pool and assign a subnet. This subnet will be assigned to the clients when they connect. In my case, I have a 192.168.2.0/24 subnet. My home subnet behind pfSense is 192.168.1.0/24, so make sure that the subnet behind pfSense and the subnet for the VPN clients don’t overlap. If you want you can provide a DNS Default Domain to the VPN clients. For example, my iPhone is not joined to my local domain, so when I connect to VPN and I want to access a server on a local network, I don’t have to specify the FQDN. It will be automatically added. In addition, make sure you provide a list of DNS Servers. In my case, the first two are my local Domain Controllers and the third one is the Google’s DNS, in case the first two are down. You can also provide a login banner, although I never saw where does that shows up on any of the clients.

pfSense IPsec tunnel Phase 1

Go back to the Tunnels tab and click on Add P1. Fill out the first section, so it looks like this.

For the second section Phase 1 Proposal (Authentication), make sure that you enter the FQDN of your pfSense. This value MUST be the same as the one that you used when creating the certificates. For My Certificate, choose the certificate that you just created.

For the thirds section Phase 1 Proposal (Algorithms), choose AES256, SHA256 and DH Group 14.
And for the Advanced Options, set it up like the screenshot below.

pfSense IPsec tunnel Phase 2

For the phase 2 of the tunnel, use these settings. In my case I choose Network and 0.0.0.0/0. This means that all the traffic from the clients will use the tunnel. For example, once connected, if you open up a browser and type what’s my IP in Google, you’ll get the external IP of the pfSense box. If you choose LAN Subnet, then only the traffic destined for your local home network will be using the VPN. The other Internet traffic will use whatever gateway you are connected to. For example, if I am using my iPhone connected to VPN and I use the Verizon network, the VPN will work, but if I type what’s my IP in a browser, I’ll get the external IP that Verizon provided me.

Use the following settings for the SA/Key Exchange.

You don’t have to do anything under Advanced Configuration.

pfSense Client Pre-Shared Keys

For each client, you will need a certificate and a username/password combo. You can’t connect with the same username and password from two different clients at the same time. The client that connects later will kick the former. So, go to VPN | IPsec and click on Pre-Shared Keys tab. Click Add to add a unique user. Make sure you choose EAP for Secret type. The Identifier is your user name, the Pre-Shared Key is your password.

pfSense Firewall Rules for IPsec

You will also need a rule that will allow the IPsec traffic. In my case, I will allow all the traffic that comes from the VPN clients. Go to Firewall | Rules and click on IPsec tab.
Pretty much,you’ll have to create a rule that looks like this.

…and this. Don’t change anything under the Display Advanced.

When you are done, it will look like this screenshot.

pfSense Export Certificate

The final step is to export the certificate. You will have to give this to each client along with their username and password. The certificate is the same for all of them. Go to System | Cert. Manager and click on CA tab. Under the Actions, click on the icon that looks like a sun.This will download a certificate in a PEM format. Send this file to your users however you find it fit. Do not send the certificate and the username and password in the same e-mail. Do not store them together. That’s what best practices say. :)
OK, we are done with pfSense, let’s move to the clients.

Windows 10, Windows 2012R2, Windows 2016 clients

These OSes work out of the box. There is no need to install any clients and no updates or service packs are needed. But, there are some changes that have to be made.

CA certificate

First, you’ll have to install the certificate from pfSense, the one that you’ve just downloaded. Transfer it to the Windows client and double-click on it. When the certificate shows up, click on Install Certificate.

Select Local Machine.

Select Place all certificates in the following store, then click Browse and choose Trusted Root Certification Authorities.

Click Finish. You should get a pop-up saying that the import was successful.

Registry change

By default, Windows uses DH Group-2. This is a bit outdated and you’ll see later that strongSwan VPN client for Android dropped the support for this. So, we have to tell Windows to use IKEv2 with AES256 and SHA256 with DH14. Check this link for more info (look at table 2). In essence, we need to create a new registry entry and reboot. So, launch regedit and create a new DWORD key under HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters.

The name of the key is NegotiateDH2048_AES256 and the value is 2.

Reboot.

Create the VPN connection

We’ll create the VPN now. Fire up powershell and execute these commands. Replace the ServerAddress parameter with the FQDN of your pfSense. For a detailed explanation of these commands visit the links here and here.

Add-VpnConnection -Name "VPN2HOME" -ServerAddress "mysweethome.mysweetdomain.com" `
-TunnelType IKEv2 -AuthenticationMethod EAP -EncryptionLevel "Required"
Set-VpnConnectionIPsecConfiguration -ConnectionName "VPN2HOME" `
-AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256  `
-EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru

Say “Y” when prompted and you should see this.

If you go to your Network Connections, you’ll see the VPN connection that you’ve just created.

Right click and choose Connect/Disconnect. Enter the username and password.

You are good!

If you go to a command prompt and do ipconfig, you’ll see that you have an IP 192.168.2.1. That’s the subnet that we allocated for the remote clients. As you can see, I can ping an internal resource.

Remove the certificate (optional)

If you want to remove the certificate for some reason, you can start the Certificate Manager as Start | Run, type certmgr.msc and then under Trusted Root Certification Authorities you’ll see your certificate. Right click and Delete.

iPhone 11.2.6

iPhone also works without any clients installed. I am not sure if earlier versions of iOS will work, but according to this Apple support document, you should be able to use AES256/SHA256/DH14 as of iOS 9.3.

CA Certificate

The easiest way is to send the certificate as attachment. Once received in your e-mail, just tap on it.

In the upper right corner, tap Install.

You’ll get a warning, bypass it by tapping on Install again in the upper right corner.

Create the VPN connection

Tap on Settings and then General. Scroll a bit down until you see the VPN option.

Tap on Add VPN Configuration.

Choose IKEv2 for the Type, enter a Description and use the FQDN of your pfSense box for both Server and Remote ID.

Under the Authentication section, choose Username for User Authentication and then enter your username and password. Tap Done in the upper-right corner when completed.

Now, you can connect. Slide the button to the right under Status and within a second or two, you should be connected.

You will see a VPN icon in the top portion of the screen, right next to your cell signal strength icon.

Remove the certificate (optional)

If you want to remove the certificate, tap on Settings | General, then scroll until you see the VPN entry. Right below, you’ll see an entry that says Profile. Tap on Profile. Tap on the Configuration Profile.

Tap on Remove Profile.

Or, you can go to Settings | General | About and then tap on Certificate Trust Settings to see your certificate.

Ubuntu 17.10 (artful) and GNOME

Ubuntu 17.10 doesn’t work out of the box, so some changes are needed. Same with the other clients, we’ll need a certificate and some libraries and plugins enabled.

CA Certificate

Transfer the pfSense CA certificate to your Ubuntu box. In my case, I’ve sent the certificate in an e-mail and then downloaded the certificate under Download folder from Firefox. We’ll have to make this certificate trusted in the certificate store. In a terminal window, do the following. You need to type what’s highlighted, the rest is the output. Pretty much, I am copying a file called pfSense+CA.crt to a folder called /usr/local/share/ca-certificates and the 2nd command is to update the CA certificates.

sudo cp Downloads/pfSense+CA.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Install libraries and plugins for strongSwan client

By default, there is no IKEv2 support in GNOME Network Manager, so we’ll have to install the necessary libraries. From a command prompt install the network-manager-strongswan plugin and the libraries for the extra plugins (eap-mschapv2 and eap-identity) that come with libcharon-extra-plugins.

sudo apt-get install network-manager-strongswan libcharon-extra-plugins

This is what it looks like if I check the version.

dpkg-query -l | grep swan
ii  libstrongswan                              5.5.1-4ubuntu2.2                            amd64        strongSwan utility and crypto library
ii  libstrongswan-extra-plugins                5.5.1-4ubuntu2.2                            amd64        strongSwan utility and crypto library (extra plugins)
ii  libstrongswan-standard-plugins             5.5.1-4ubuntu2.2                            amd64        strongSwan utility and crypto library (standard plugins)
ii  network-manager-strongswan                 1.4.2-1                                     amd64        network management framework (strongSwan plugin)
ii  strongswan-libcharon                       5.5.1-4ubuntu2.2                            amd64        strongSwan charon library
ii  strongswan-nm                              5.5.1-4ubuntu2.2                            amd64        strongSwan plugin to interact with NetworkManager
ii  strongswan-tnc-base                        5.5.1-4ubuntu2.2                            amd64        strongSwan Trusted Network Connect's (TNC) - base files
dpkg-query -l | grep charon
ii  libcharon-extra-plugins                    5.5.1-4ubuntu2.2                            amd64        strongSwan charon library (extra plugins)
ii  libcharon-standard-plugins                 5.5.1-4ubuntu2.2                            amd64        strongSwan charon library (standard plugins)
ii  strongswan-libcharon                       5.5.1-4ubuntu2.2                            amd64        strongSwan charon library

Create the VPN connection

In the upper right corner, click on the icon for the network and choose VPN Settings.

Click on the plus (+) sign to create a new VPN connection.

Choose IPsec/IKEv2 (strongswan).

Then fill out the form as below. If you are unable to type the password, click on the icon marked with the red arrow and choose one of the options provided for storing the password.

Finally, click on the slider to enable VPN. If you have any issues, you can look at the logs at /var/log/syslog.

Remove the certificate (optional)

This is a local CA certificate file, so you can just delete the crt file that you’ve downloaded from /etc/ssl/certs, the Download folder and /usr/local/share/ca-certificates/.

Mac OS X 10.13.3 High Sierra

I’ve tested this configuration on High Sierra, but it should work for all OS X 10.x versions. As usual, I’ll start with the certificate.

CA Certificate

Transfer the certificate to your Mac and double click on it. It will prompt you for your admin password. Once completed, the Keychain will open up. This is where the certificates are stored. Find your certificate under System and double-click on it.

You’ll see that the certificate is not trusted, so expand the Trust and change When using this certificate to Always Trust.

Create the VPN connection

Go to your System Preferences and click the Network icon.

Click on the plus (+) icon in the bottom left corner.

Change the Interface to VPN, VPN Type to IKEv2 and enter some description for the Service Name.

For the Server Address and Remote ID enter the FQDN name of your pfSense box. Click on Authentication Settings.

For the Authentication Settings choose Username and enter your username and password. Once you click OK you’ll go back o the previous dialog box where you can click Connect.

Remove the certificate (optional)

If you want to remove the certificate, all you have to do is to launch Keychain (Go | Utilities | Keychain Access.app), find your certificate, right-click and Delete. You’ll be prompted for the admin password to do that.

Android 6.x Marshmallow

I’ve tested the configuration on an Android 6.x tablet and strongSwan client v1.9.6. From what I see, as long you use this client, you should be able to use the VPN even with Android 5.

CA Certificate

Get the certificate on the device. In my case, I sent the certificate over e-mail and used the Firefox browser to access my web based e-mail. I’ve downloaded the certificate under Downloads folder on my Android tablet. You don’t have to do anything with the certificate now, just remember where it is.

Install the strongSwan client

Go to the app store (Google Play), download and install the strongSwan client.

Create the VPN connection

Open the strongSwan client and in the upper right corner, tap on the three vertical dots.

Then tap on CA certificates.

Tap on Import certificate.

Select the CA certificate that you’ve just downloaded.

Tap on Import Certificate.

Once imported, go back and tap on Add VPN Profile. Fill out the form so it looks like this. For the Server, enter the FQDN of the pfSense box, choose IKEv2 EAP for VPN Type, enter the username and password and then uncheck Select automatically for CA certificate.

Tap Select CA certificate, tap on Imported and select the certificate that you’ve imported.

Click Save in the upper right corner and you are ready to connect.

CentOS 7 (non-GUI)

The CentOS 7 client that I am using comes with firewalld enabled and SElinux disabled. You don’t have to make any firewall changes.

Install strongSwan

strongSwan doesn’t come up in the standard repo, so you’ll have to install the EPEL first.

yum install epel-release

Then install strongSwan and enable it so it starts on boot.

yum install strongswan
systemctl enable strongswan

CA Certificate

Get the certificate and place it under /etc/strongswan/ipsec.d/cacerts. We will need the DN (Distinguished Name) from the certificate. Replace certfilename.crt with the name of your certificate file.

openssl x509 -noout -in /etc/strongswan/ipsec.d/cacerts/certfilename.crt -issuer

You’ll see something like this:

issuer= /C=US/ST=XY/L=Town/O=something/emailAddress=user@somedomain.com/CN=whatever/OU=YX.

Copy the value that’s after = /.

Create the VPN connection

Go to /etc/strongswan and edit ipsec.conf. Make sure your config file looks like this. Replace the values for right and put your FQDN of your pfSense box, enter the username under eap_identity and paste the value for the DN under rightca.

conn rw-base
    dpdaction=restart
    dpddelay=30
    dpdtimeout=90
    fragmentation=yes

conn vip-base
    also=rw-base
    leftsourceip=%config

conn ikev2-eap-mschapv2
    also=vip-base
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    leftauth=eap-mschapv2
    rightauth=pubkey
    right=mysweethome.mysweetdomain.com
    eap_identity=darth.vader
    rightca="C=US/ST=XY/L=Town/O=something/emailAddress=user@somedomain.com/CN=whatever/OU=YX"
    rightsubnet=0.0.0.0/0
    auto=add

Edit ipsec.secrets and enter your username and password.

# ipsec.secrets - strongSwan IPsec secrets file
darth.vader : EAP "DeathStar01"

Finally, launch the connection.

systemctl restart strongswan
strongswan up ikev2-eap-mschapv2

BTW, you can replace the ikev2-eap-mschapv2 with vpn in ipsec.conf file (line 11), so you can start the connection as strongswan up vpn.
You can bring the connection down with…down.

strongswan down ikev2-eap-mschapv2

You should be able to ping the internal resources now. I wasn’t able to ping the resources internally using the FQDN, only by IP. There is something how CentOS/Fedora compiled the package. See this link.
I didn’t bother to investigate further.

FreeBSD (non-GUI)

FreeBSD comes up with the generic kernel already configured for IPsec. I didn’t test my config if my FreeBSD client is behind the NAT, but I think you should recompile the generic kernel and add support for NAT_T. Not 100% sure though, it’s on my to do list. So, this config will probably work only if your FreeBSD box has a public IP.

Install strongSwan

Install strongSwan from the packages.

pkg install strongswan

Let it start on boot. Add this line in /etc/rc.conf.

strongswan_enable="YES"

CA Certificate

Get the certificate and place it under /usr/local/etc/ipsec.d/cacerts. We will need the DN (Distinguished Name) from the certificate. Replace certfilename.crt with the name of your certificate file.

openssl x509 -noout -in /usr/local/etc/ipsec.d/cacerts/certfilename.crt -issuer

You’ll see something like this:

issuer= /C=US/ST=XY/L=Town/O=something/emailAddress=user@somedomain.com/CN=whatever/OU=YX.

Copy the value that’s after = /.

Create the VPN connection

Go to /usr/local/etc and edit ipsec.conf. Make sure your config file looks like this. Replace the values for right and put your FQDN of your pfSense box, enter the username under eap_identity and paste the value for the DN under rightca.

conn rw-base
    dpdaction=restart
    dpddelay=30
    dpdtimeout=90
    fragmentation=yes

conn vip-base
    also=rw-base
    leftsourceip=%config

conn ikev2-eap-mschapv2
    also=vip-base
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    leftauth=eap-mschapv2
    rightauth=pubkey
    right=mysweethome.mysweetdomain.com
    eap_identity=darth.vader
    rightca="C=US/ST=XY/L=Town/O=something/emailAddress=user@somedomain.com/CN=whatever/OU=YX"
    rightsubnet=0.0.0.0/0
    auto=add

Edit ipsec.secrets and enter your username and password.

# ipsec.secrets - strongSwan IPsec secrets file
darth.vader : EAP "DeathStar01"

Finally, launch the connection.

service strongswan restart
ipsec up ikev2-eap-mschapv2

BTW, you can replace the ikev2-eap-mschapv2 with vpn in ipsec.conf file (line 11), so you can start the connection as ipsec up vpn.
You can bring the connection down with…down.

ipsec down ikev2-eap-mschapv2

You should be able to ping the internal resources now.

In this post I’ll describe how to configure a tunnel between pfSense and AWS. At home I have a box running pfSense 2.4.2 as a firewall/gateway and my internal network is 192.168.1.0/24.
First things first, let’s configure AWS.

AWS

Log to your AWS account and go to your VPC. On your left side at the bottom, you’ll see these items.

Click on Customer Gateways first and then click to create a Customer Gateway. Name your gateway connection and enter the external IP of your pfSense box.

Go back to the same entries on the left and click to create a Virtual Private Gateway. Name your Virtual Private Gateway.

Go back again and this time click the last option to create a VPN Connection.
Name it, choose the Virtual Private Gateway that you just created and also choose the Customer Gateway that you created initially.

For the Routing Options, select Static and enter the subnet that’s behind your pfSense. If you have more subnets at home/work, add them all if you want to be reachable.
You don’t have to enter anything for Tunnel Options.

Go back to the initial entries and click Virtual Private Gateway. Select your Virtual Private Gateway and from the Actions, choose Attach to VPC.

Choose the VPC that you will use.

Again, go back to the initial entries, select VPN Connections and click on Download Configuration.

When prompted, choose the configuration for pfSense.

You’ll get a text file. Make sure you open this with Wordpad or Notepad++. Notepad won’t display it correctly. This file tells you pretty much what to do on the pfSense side.

pfSense

Go to your pfSense box and choose VPN | IPsec from the menus. You’ll see something like this.

Click on Add P1. Fill out the values from the text file that you just downloaded from AWS. It looks like this.

…and this.

…and this.

…and finally this. Click Save.

Click Apply and then click on Add P2.

As with Phase 1, do the same for Phase 2. Read the values from the text file so it looks like this. For the Remote Network subnet, enter the subnet of your VPC. You can get that if you click on the VPC and check the IPv4 CIDR column.

Keep entering the values.

For some reason, my VPN tunnel got disconnected a lot if there was no traffic, so under Advanced Configuration I had to enter an internal IP of an AWS instance to be pinged all the time to keep the traffic flow.
Click Save and then Apply Changes.
Now, we have to allow the traffic coming from AWS to our internal network.
From the menus in pfSense, go to Firewall | Rules and click on IPsec. Click Add and allow the traffic that suits your needs. In my case, I allow all the traffic.

..and this.

Once you apply the changes it should look like this.

Go to Status | IPsec from the menus and click Connect. If everything is OK, you’ll see the connection established.

Now, we have the rules in place that allows the traffic originating from AWS to pfSense to pass through, but if you want the traffic originating from your internal network to reach AWS, you’ll have to assign AWS Security groups to the instances that allow traffic from your internal network.
In my case, I have a security group that looks like this. It is assigned to all of my AWS intances. It allows traffic from my internal network to reach AWS.

But that’s not all. Because we are using static routes, we have to tell AWS to use the Virtual Private Gateway to reach our internal network. If you go back to AWS and click on route tables you’ll see something like this.

This means that all the traffic that goes to 172.31.0.0/16 subnet, which is the VPC’s internal subnet should use local routing and all other traffic to use igw-b31598d6 which is the Internet gateway. But, we don’t want that. If an instance in AWS tries to reach an instance behind pfSense it will try to reach it over the Internet. So, we have to tell AWS to use the Virtual Private Gateway for our local subnet.
So, click on Route Propagation and see how the Propagate field says No. We have to Edit that and check the checkmark, so all the internal traffic uses the Virtual Private Gateway.

Once completed you should see something like this under the Routes.

At this point you should be able to reach all instances back and forth. Also, make sure that the VPN tunnel is UP on the AWS side. Don’t worry about the second tunnel down. By default, AWS provides you two redundant tunnels. Since we have only one pfSense with a single public IP, we don’t have to worry about the 2nd tunnel…unless you have 2 pfSense boxes in a cluster with 2 public IPs.

In this blog post I’ll describe how to create a VPN connection between an Azure subscription and a pfSense router with a public IP using dynamic routing. Before we proceed, you have to understand that the subnets can’t overlap in Azure and behind pfSense. So, if your home network is 192.168.1.0/24, you can’t have the same subnet in Azure. It is also a good practice to write down your subnets and subnet masks before hand, so there are no errors when creating the tunnel. Many times, the tunnel won’t work just because you are rushing things and not paying attention to the subnets and masks. So, here is my setup.

In my home lab I have a pfSense with a public IP (1.2.3.4) and my internal network behind pfSense is 192.168.1.0/24. In Azure, I will create a subnet for the servers that will be part of a bigger network. So, I’ll create a vNet with an address space of 10.0.0.0/23, I’ll carve a smaller subnet 10.0.0.0/24 and use the rest 10.0.1.0/24 for the Virtual Network Gateway. Write down your values.

Create Azure VPN

Virtual Network and subnets

Log in to Azure (the new portal using Resource Manager), select your default subscription or if you have only one (Pay As You Go), just go and create a new vNet. Fill out the necessary values to suit your needs and click Create.

I will have 256 IP addresses for the servers and 256 IPs for the gateway.
Once the vNet creation completes, usually in 10-15 seconds, click on the bell icon in the upper right corner and click on Go to resource.

There, click on Subnets.

Click on Gateway Subnet.

Verify the settings, but for me Azure filled out the subnet correctly with 10.0.1.0/24. You can’t change the name of this subnet. Just click OK.

Virtual Network Gateway

Virtual Network Gateway is the the actual VPN tunnel. Click on New, Networking and then Virtual Network Gateway.

I used the following values when creating the gateway.For the SKU, I choose Basic. To see what each of them means, visit this link, pretty much it’s about the number of connections and the bandwidth that you’ll get. Choose the vnetAzure for the Virtual network and create a new Public IP address. I named my IP ipVPN. Click Create at the end. The creation takes about 30 mins. Once created, click on the ipVPN resource that you created and get your public Azure IP. Write this value down.

Local Network Gateway

Once the Virtual Network Gateway is provisioned, go and create a Local Network Gateway.

In my case, it looks like this. The IP address 1.2.3.4 (of course not) is the public IP of my pfSense at home and the address space 192.168.1.0/24 is my home network behind the pfSense. Choose the same resource group as the vNet, virtual network gateway tunnel and the same location. Click Create.

Connections

Once created, select your local network gateway and click on Connections.

Click Add.

Choose a name, in my case connVPN, choose the virtual network gateway and the local network gateway that we just created and create your shared key. This is the key that the IPsec tunnel will exchange when establishing connection. Choose something more complex and longer, not something like I used.

Once the creation finishes, you are pretty much done in Azure for the first part.

pfSense

VPN/IPsec

Log in to your pfSense and from the menus go to VPN/IPsec. Click on Add P1 at bottom right. This is to create the first phase of the IPsec tunnel negotiation.

Fill out these values and make sure that you replace with your IPs. For the General Information section I used this. 52.168.160.233 is my Azure public IP. Yours is different.

For Phase 1 Proposal (Authentication) use these values and enter your shared key.

For Phase 1 Proposal (Algorithms) use these values.

For the Advanced Options, use these values and click Save.

Once the screen goes back to the main VPN/IPsec/Tunnels menu, click Apply Changes. From the same screen, click Show Phase 2 Entries for the entry we just created. I have two, the first one is for AWS, so I used the 2nd one.

Click Add P2.

For the General Information section, use these values. Under Remote Network, enter the vNet Address Space, not the server subnet. Look all the way above and make sure you have the same values in what you’ve written and what are you typing here.

For the Phase 2 Proposal (SA/Key Exchange) I am using these values.

Finally, for the Advanced Configuration, you can leave it as is and click Save. I’ve noticed that if there is no activity in the tunnel between the resources in Azure and my home, the tunnel shuts down from time to time. But, if I enter an IP of an Azure server here, pfsense will ping this host so the traffic will flow constantly and the tunnel stays up. Of course, you have to make sure that your Azure resource allows ICMP in a security group (which is not by default).

OK, now that you have your P2 phase set up, click Apply Changes again. From the main menu, go to Status, IPsec and you should see your tunnel established.

pfSense is locked down quite a bit by default, so we have to open up the firewall for the IPsec traffic. In order to do that, from the main menu go to Firewall, Rules and then click on the IPsec sub-menu.

Click Add and fill out the form with the following values. This will allow all traffic to flow from Azure to pfSense without any restrictions. If you want to restrict the rules, e.g. you don’t want ping to be allowed, then you have to create a rule to deny ICMP or create two rules, one for TCP and one for UDP. In my case, I don’t mind all the traffic so I used any to any.


There are no Advanced Options needed. Just click OK and you are good to go.

Test

In order to test, I’ll build a new Windows 2016 VM. Make sure that this VM is in the same resource group as the VPN gateway, uses the vNet that we created and that the subnet is the one for the servers, subServers. You don’t need a public IP. Once you provision this VM, go to the Networking properties of the VM and look up the internal IP. It should be in the same subnet as the subServers subnet. In my case it’s 10.0.0.4.

At this point you should be able to RDP to this VM, but ping won’t work. Why? Because, when you create a VM in Azure, it creates a security group that allows RDP only, but not ping (ICMP). Now, if you log to your new VM in Azure and try to ping a resource on your local home network, you’ll see that you can ping it. Why? Because in pfSense we created a rule that allows all traffic from Azure to pfSense to pass. If you want all traffic in both directions, you’ll need a new security group in Azure that allows all traffic and attach this security group to your instances.

I use Plex to watch some of my movies, but I’ve always watched them from home. Because I was going on vacation, I decided to enable Plex to stream my movies over the Internet. My pfSense is release 2.3.4 and Plex is 1.7.5.4035.

My home network is behind a pfSense, so I had to create some NAT rules in the firewall to allow outside access. But first, let’s configure Plex. Open your server GUI and click on the Settings icon in the upper right corner.

Then click on the Server menu and Remote Access sub menu. Click on Manually specify public port and enter 32400. Click Apply.

In pfSense, go to Firewall then NAT from the menus. Click Add and enter the following values.

– Destination Port Range, (other) – 32400, (other) – 32400
– Redirect Target IP – 192.168.x.y (or whatever your internal IP for the Plex server is)
– Redirect Target Port – 32400
– Description – Something like Plex Remote Access
– NAT Reflection – Enable (NAT + Proxy).

Click Save and Apply Changes. You can now access your content, but Plex GUI won’t show the changes. Just log off and log back on and you should see the green check for OK. If not, click Retry.

I used pfSense a lot in the past 6 months, but I never got any chance to write about it. So, for my 100th post, I’ll talk about it a bit and this will be a placeholder for future reference.

At my home, I was using a Netgear Nighthawk AC1900 (R7000), but this Wi-Fi router has a lot of limitations. I’ve decided to go with a full blown PC, but I needed a one that’s not a desktop/laptop size. After some research I’ve decided to buy Qotom-Q180S from Amazon. It’s about $150 and it arrived in 3 days from Hong Kong. It’s great because there are no moving parts (no fan, no HDD).

First, go to https://www.pfsense.org/download/ and download the ISO.

Use something like Rufus to transfer the image to an USB stick.

Go to the BIOS and choose to boot from USB. You can also see how big is the unit compared to a pen.

When pfSense boots up, you’ll see something like this.

Use the default.

Choose Custom install.

Choose the SSD drive (32GB) that comes with the unit, not the USB drive.

Format the disk, the unit comes with Windows 7 that’s not activated.

Just use the defaults.

Yep, format.

Tab to Accept and Create and hit Enter.

Same thing, Accept and Install Bootblocks.

Use the default.

It’s all defaults, 4GB of swap because I have 2GB RAM.

Use a standard kernel.

Hit reboot and remove the USB stick.

Once it comes back, choose no for VLANs.

At this point, you’ll have to know where you plugged your cable from your cable/DSL modem into the unit. You should plug your external cable to the NIC that’s marked as 1 and your internal switch or Wi-Fi router to NIC2. pfSense marks them as re0 and re1. re0 is the NIC1, re1 is NIC2. I used re0 because my cable modem is connected to NIC1.

Use re1 for the internal LAN.

Hit Enter key.

Verify all is OK and type y to proceed.

At this point you are all set. The IP for the internal interface is set to 192.168.1.1/24.
All you have to do is to point all your internal devices to use 192.168.1.1 as gateway and be on the same subnet.

You can log in to http://192.168.1.1, use admin/pfsense as password.
In my next posts I’ll go over VPN, squid etc…

In this post I’ll describe how to establish a site to site connection with Amazon’s AWS cloud. We’ll use pfSense 2.2, build two instances in the cloud and expand our internal network to Amazon over IPsec tunnel. Make sure that you use pfSense 2.2. They’ve changed the IPsec from racoon to strongswan in this version, so I am not sure if the scenario described below will work with earlier versions. It should, because the parameters are the same, but you never know. In this post, I won’t hide any IPs or shared keys. These instances will be long gone when you read this.

Make sure you have a working pfSense instance with WAN and LAN adapters already configured. You will need this info. The public IP, the local IP and the local subnet. In my case the local subnet for the LAN IP is 10.99.0.0/16.

AWS

Log on to AWS portal and select VPC.

Click on Start VPC Wizard button.

Choose the third option, VPC with Public and Private Subnets and Hardware VPN Access. We’ll build two instances (VMs). One in the public space and one in the private space. The public instance can be reached from outside, but this instance can also reach the private instance. The private instance can reach the public instance and our local network.

I’ll use 10.100.0.0/16 as a VPC subnet and then carve two smaller subnets, 100.100.0.0/24 which will be my Public subnet (named BLOG Public subnet) and 10.100.1.0/24 as my Private subnet (named BLOG Private subnet).

Specify the Customer Gateway IP (that’s the public IP of pfSense), choose Static for Routing Type and enter the LAN subnet on the pfSense side. Name the Customer Gateway and VPN Connection accordingly and click on Create VPC.

Once completed (after 2-3 minutes), click on Virtual Private Gateways and name your gateway.

Click on Route Tables and rename your routes. You will notice that the route for the public subnet has BLOG Public subnet associated. Name this route as Public Route or however you want. In my case it’s BLOG Public Route.

Click on the other route and name it, in my case BLOG Private Route. Then click on Subnet Associations and click Edit.

Associate this route with the BLOG Private Subnet and click Save.

At this point, we’ll create two Amazon Linux instances, but let’s see what we have.

Go back to the home screen and click on EC2.

I won’t go into details, but pick Amazon Linux AMI, choose the CPU/RAM resources (micro, small, etc…), and then select the proper VPC, the public subnet and enable auto public IP as below. This is our AMI with public access.

Tag the instance so you know which one is the public.

Create or use an existing security group, just make sure SSH is allowed.

And finally create or reuse an existing key pair. It doesn’t matter as long as you know how to use this. Then, create another instance, this time use the private subnet. Name the instance accordingly.

From a public IP, ssh to the public AMI. I won’t go into details (see this link), but copy the key to this AMI and from here, duplicate this session in putty and ssh to the private AMI. It looks like this on my computer. So, the idea is to ssh to the public, copy the ssh key to the public in order to access the private AMI.

You can use the public AMI as a backdoor to get to the private AMI. Without the tunnel, you won’t be able to log to the private AMI. Before we can create the tunnel, go back to the VPC menu, click on the VPN connections and then Tunnel Details tab. Get the IPs. We’ll use only the first one. You can create two IPsec tunnels in pfSense if you want. It’s the same procedure. AWS uses two IPs for their gateways for redundancy.

Now that you have the external IPs of the Amazon gateway, click on Download Configuration and choose the generic one. Open this file with Wordpad or Notepad++. Notepad won’t work, there is no support for U*NIX line-endings.

pfSense, IPsec

Switch back to pfSense and from the menu, select VPN | IPsec.

Check Enable IPsec and create the Phase 1 (the plus sign on the right).

In the General Information section, enter the external IP of the Amazon’s gateway. If you open the configuration file that you downloaded, you can find that information there as well. Ignore 169.254. addresses.

The Customer Gateway inside IP address should be configured on your tunnel
interface. 

Outside IP Addresses:
  - Customer Gateway 		        : 104.207.133.238 
  - Virtual Private Gateway	        : 207.171.167.234
		
Inside IP Addresses
  - Customer Gateway         		: 169.254.255.38/30
  - Virtual Private Gateway             : 169.254.255.37/30

Configure your tunnel to fragment at the optimal size:
  - Tunnel interface MTU     : 1436 bytes

Make sure that you have a small table like this, so you don’t get confused with subnets and IPs.

For Phase 1 section, enter the Pre-Shared Key and change the Encryption algorithm to 128 bits.

Finally, in the Advanced Options section, change the parameter for Dead Peer Detection from 5 to 3 retries and click Save.

Click the “+” sign for Phase 2.

…and again the “+” sign for Phase 2 entry.

In the first section of Phase 2, add the local subnet on Amazon’s side (10.100.1.0).

In Phase 2 proposal section, change the value for AES to 128 bits and PFS key group to 2. Click Save.

From the menu, go to Status | IPsec.

And you should see that the tunnel has been established.

AWS routing

Go on the Amazon side, click VPN Connections and verify that the tunnel is up too.

While there, click on the Route Tables on the right, then select your Private Subnet. Under Routes tab, see if pfSense local subnet is there and that it says Propagated. If not, go back to VPN Connections, then Static Routes and click Edit. Add 10.99.0.0/16. Wait until Pending becomes Available (usually 5-10) seconds.

Then, go to the Route Tables , tab Routes and see if the route propagated successfully for the Private Route (in my case it’s BLOG Private Route).

If the 10.99.0.0 (pfSense LAN) route is not there, click on Route Propagation tab and make sure that the setting for route propagation is set to Yes.

pfSense routing

In order to access our instance at Amazon, we have to add a new route.  Go back to pfSense and click on System | Routing.

On the Gateway tab, click the “+” sign.

Change the interface to LAN, name the gateway (in my case GW2AWS), enter the GW IP (that’s the local pfSense LAN IP, in my case 10.99.0.11) and click Save.

Click the Routes tab and then the “+” sign. Add a new route. Make sure you choose the gateway that we just created. The destination network should be 10.100.1.0/24. Click Save.

Finally, go to Diagnostics | Routes and wait for the routes to show up. In my case it looks like this. Verify that you have the route between pfSense local subnet and AWS local subnet.

Testing

Since both pfSense and the AMIs are quite locked, we won’t have much choice in the testing scenarios. We know that ssh port is open on the AMIs, so go to the pfSense console and choose option 8 for shell access. There do:

ssh 10.100.1.136

If you receive something like this, you are good.

Now, pfSense is very-very locked by default. It doesn’t accept ssh and https is very limited to specific IPs. But, we can create a temp rule, just for the test. Go to Firewall | Rules, select the IPsec tab and create a rule to pass ICMP traffic as below.

Go back to the Amazon AMI and do:

ping 10.99.0.11

You should get a response from the pfSense box.

If you made it congrats, now you have full site to site connection. It’s up to you how you want to configure the firewall rules on pfSense side or security groups on Amazon’s side.