In this first example, we will create a tunnel between two networks separated by the internet. This simulates a VPN tunnel that might be set up if we had to connect two facilities run by the same company, but separated by some distance. The endpoints for the tunnels will be the WAN interfaces of two separate pfSense firewalls, and we will have to perform essentially identical configurations on both ends.

We begin by navigating to VPN | IPsec. On the default tab, Tunnels, we set up the Phase 1 entry first, which we begin by clicking on the Add P1 button. In the General Information section, we change the Key Exchange version to IKEv2. We set the Remote gateway to the IP address of the second pfSense firewall. Enter a brief Description in the corresponding edit box. In the Phase 1 Proposal (Authentication) section, we enter a key into the Pre-Shared Key edit box. In the Phase 1 Proposal (Algorithm) section, we set the Hash Algorithm to SHA256 for added security. All other values can be kept at their default values. Click on the Save button to save the Phase 1 configuration.

On the Tunnels page, click on the Show Phase 2 Entries button that corresponds to the Phase 1 entry we just created. The Phase 2 section will be empty, but we can click on the Add P2 button to create the Phase 2 entry for this connection. In the General Information section, Local Network will be set to LAN subnet, which in most cases is what we want. We need to enter the LAN subnet and CIDR of the remote network (the network behind the second pfSense firewall) for the Remote Network (we can also change the setting in the Remote Network drop-down box to Address and enter a single address). You can enter a brief Description in the corresponding edit box. In the Phase 2 Configuration (SA/Key Exchange), make sure AES256-GCM is selected. For Hash Algorithms, select SHA256. All other values can be kept at their default values. Click on the Save button to save the Phase 2 configuration.

Before the IPsec connection can be used, we must add a firewall rule to allow IPsec traffic. Navigate to Firewall | Rules and click on the IPsec tab. On this page, click on one of the Add buttons to add a rule. Under Source, select Network in the drop-down box and enter the subnet and CIDR of the remote network (this should be identical to the information entered for Remote Network in the Phase 2 configuration). All other values can be kept at their default values. Click on the Save button to save this rule. 

Now we need to repeat this configuration on the second pfSense firewall. Starting by navigating to VPN | IPsec and setting up the Phase 1 configuration, create a Phase 1 setting identical to the one on the other firewall, but make sure Remote gateway is set to the first pfSense firewall (therefore, the Remote gateway setting on each firewall will be different). When you create the Phase 2 entry, the settings will be identical to the settings on the first pfSense firewall, but make sure Remote Network is set to the subnet and CIDR of the network behind the first pfSense firewall. Once you have completed Phase 1 and Phase 2 configuration, create an IPsec firewall rule; the rule can be identical to the rule created on the first pfSense firewall.

Now that we have configured our IPsec connection on both firewalls, we can establish a connection. From either firewall, navigate to Status | IPsec. There you will see a table showing all available IPsec configurations. Click on the Connect VPN button corresponding to the configuration we just created. The IPsec tunnel should now be up and the Status column should change from Disconnected to ESTABLISHED to reflect this. Navigate to Status | IPsec on the other firewall and the table there should also display an established connection.

Now that we have set up an IPsec tunnel, what can we do with it? We can access resources on the LAN side of the remote connection as if they were local resources. For example, if there is an FTP server or Samba file share on the remote LAN, we would be able to access them, with the only real limitations being the bandwidth of our internet connection, the latency associated with accessing remote nodes, and the processing overhead of maintaining an encrypted tunnel.