IPSec VPN with pfSense using a Pre-Shared Key, Part 2

Let's remember our network:

As you can see, I have two pfSense boxes here:

One that has a WAN IP address of 172.20.0.1 and LAN IP address 10.0.0.1;
Another that that a WAN IP address of 172.30.0.1, LAN IP address 192.168.100.1 and OPT1 IP address 192.168.110.1.

What I want to do is create an IPSec VPN tunnel between the 10.0.0.0/24 and the 192.168.100.0/24 network. Remember, all settings must be the same between our two firewalls.

Time to go to our second node (192.168.0.100.1) and select VPN->IPSec.

Now select the "Tunnels" tab (if not already there) and click on the "+" (add phase1 entry).

Here we'll need to add the public IP address of the other gateway (in our case, the second pfSense box), which in our case is 172.20.0.1 and a description for this.

 
Now, everything below this, we should make sure that it matches our other pfSense's box settings. Here's one catch though.

Remember I had changed the identifiers? In this case, "My identifier" is this pfSense's identifier and the peer identifier is the other ones. Which means that we should reverse the user distinguished names identifiers.

Everything else is made sure to be exactly the same as the other box.

After we've saved, we should now be on our VPN:IPSec page, Tunnels tab. Click on the "+" button below our newly created Phase 1 entry, right next to the "Show 0 Phase-2 entries":

A new entry below our Phase 1 entry should now appear with the fields "Mode/P2 Protocol/P2 Transforms/P2 Auth Methods". Let's click on the "+" sign right next to it.

Now, we need to connect our LAN interface with the LAN interface of the other pfSense box. In other words, I'll need to choose "LAN subnet" as the local network and "10.0.0.0/8" as the remote network.

Remember, everything should be the same on both sides.

Now, let's go to Firewall, Rules and click on the IPSec tab. Click on the "+".

Over here, we should allow any traffic we'd expect to see through the IPSec tunnel. For instance, if only SSH is expected then only TCP port 22 should be allowed. In reality though, most IPSec tunnels are set to allow all.

Now, we'll need to add a rule to our WAN interface so as to actually allow the other box to be able to connect in the first place. In real life situations, we might trust the incoming IPSec traffic, but allowing all from the firewall on the other side is something that is generally frowned upon (unless of course you own both boxes, in which case it's fine). From the pfSense docs:

Rules are automatically added to the WAN to allow the tunnel to connect, but if the option to disable automatic VPN rules is checked, then manual rules may be required. In that case, check the WAN rules to ensure that the traffic from the remote pfSense host is allowed. IPsec uses UDP port 500 and 4500, and protocol ESP (or AH if set that way). If there is trouble establishing a tunnel, check the firewall logs (Status > System Logs, Firewall tab), and if blocked packets are seen, add appropriate rules to allow that traffic. 

Obviously, I own both boxes so I'll just allow all from my other pfSense's IP.

Now, we need to make sure that we have enabled our IPSec service on both boxes:

pfSense 1 (10.0.0.1):

 pfSense 2 (192.168.100.1):

Let's see if it all works:

Brilliant!

IPSec VPN with pfSense using a Pre-Shared Key, Part 1

I will try to make this detailed and also try to create a relatively complicated network; something you'd run into in real life, not in ideal lab situations.

So here's the network:

As you can see, I have two pfSense boxes here:

One that has a WAN IP address of 172.20.0.1 and LAN IP address 10.0.0.1;
Another that that a WAN IP address of 172.30.0.1, LAN IP address 192.168.100.1 and OPT1 IP address 192.168.110.1.

What I want to do is create an IPSec VPN tunnel between the 10.0.0.0/8 and the 192.168.100.0/24 network. There are two ways we can do this: one is through using a Pre-Shared Key, and the other is through an RSA Signature.

We'll use a PSK for this example.

Let's go to our first node (10.0.0.1) and select VPN->IPSec.

Now select the "Tunnels" tab (if not already there) and click on the "+" (add phase1 entry).

Here we'll need to add the public IP address of the other gateway (in our case, the second pfSense box), which in our case is 172.30.0.1 and a description for this.

Next, we should leave the Authentication method to "Mutual PSK", unless we needed to use an RSA signature instead. We'll leave the Negotiation Mode to "aggresive" too. From the pfSense docs:

This is the type of authentication security that will be used. Unless extreme levels of security are called for, it is best to leave this as aggressive. It is indeed far faster and will insure that the VPN tunnel will rebuild itself quickly and probably won't time out an application if the tunnel was down when the resource on the other end was requested. (more about that under Lifetime)

In most cases, leaving the "My Identifier" and the "Peer Identifier" fields alone works, and there's no real need to change them either. From the pfSense docs:

My Identifier: Identifies this router to the far side. It is best left at My IP Address and the firewall will fill it in as needed. In some cases an FQDN or similar may be entered so that the value is constant. So long as both sides agree on the Identifier it will work.

Peer Identifier: Identifies the router on the far side. It is best left at Peer IP Address and the firewall will fill it in as needed. In some cases an FQDN or similar may be entered so that the value is constant. So long as both sides agree on the Identifier it will work.

Just for the sake of argument, I will change the identifiers. Remember, they both have to agree.

And next, we should type in our PSK.

I will also leave the "Policy Generation" and the "Proposal Checking" Fields alone. From the pfSense docs:

Policy Generation: Controls how the keying daemon creates SPD entries. Leave this at the default setting unless instructed otherwise.

Proposal Checking: Controls how strict (or loose) the Phase 1 parameters are verified during the negotiation. The default value is fine, but it is common to set Proposal Checking to Obey to avoid some issues with building a tunnel when the other side initiates. This can allow for lowered security than what has been chosen. 

Next, I will change the Encryption and Hash algorithms to more secure ones. I will leave everything else alone. From the pfSense docs:

NAT Traversal: Should nearly always be set to Disable unless it is certain that one firewall or the other has a WAN behind another NAT device.

DPD (Dead Peer Detection): This will help fully reestablish tunnel when the other side has a problem. The default values of 10 seconds and 5 retries are good.

And of course, save. Bear in mind that the settings on your pfSense boxes should be exactly the same, so anything you change here must be documented so that the same can be set on your other pfSense box.

After we've saved, we should now be on our VPN:IPSec page, Tunnels tab. Click on the "+" button below our newly created Phase 1 entry, right next to the "Show 0 Phase-2 entries":

A new entry below our Phase 1 entry should now appear with the fields "Mode/P2 Protocol/P2 Transforms/P2 Auth Methods". Let's click on the "+" sign right next to it.

Now, we need to connect our LAN interface with the LAN interface of the other pfSense box. In other words, I'll need to choose "LAN subnet" as the local network and "192.168.100.0/24" as the remote network.

I'm going to leave the "Protocol" option as is. From pfSense docs:

ESP is the de facto standard for what most VPN systems use as a transport protocol. This is the recommended setting. Note: The system should auto generate a firewall rule to allow ESP or AH to the endpoint of the VPN. If it does not, a firewall rule allowing ESP (or AH) traffic to the endpoint interface will need to be created. 

And I'll choose some stronger encryption and hash methods than the defaults. Remember, the other pfSense box should have the same ones.

Everything else I leave untouched. From the pfSense docs:

PFS Key Group: This works similarly to the DH group in phase 1. 1024 bit is a good setting, the default is off.

Lifetime: This is the lifetime the negotiated keys will be valid for. Do not set this to too high of a number (e.g. more than about a day: 86400) as doing so will give people more time to crack the key. Don't be over paranoid either; there is no need to set this to 20 minutes either. One hour (3600) is a good setting.
 
Automatically ping host: An address in the remote Phase 2 network to ping to keep the tunnel alive. See What should I ping for IPsec Keep Alive for details. 

And Save.

Now, let's go to Firewall, Rules and click on the IPSec tab. Click on the "+".

Over here, we should allow any traffic we'd expect to see through the IPSec tunnel. For instance, if only SSH is expected then only TCP port 22 should be allowed. In reality though, most IPSec tunnels are set to allow all.

Now, we'll need to add a rule to our WAN interface so as to actually allow the other box to be able to connect in the first place. In real life situations, we might trust the incoming IPSec traffic, but allowing all from the firewall on the other side is something that is generally frowned upon (unless of course you own both boxes, in which case it's fine). From the pfSense docs:

Rules are automatically added to the WAN to allow the tunnel to connect, but if the option to disable automatic VPN rules is checked, then manual rules may be required. In that case, check the WAN rules to ensure that the traffic from the remote pfSense host is allowed. IPsec uses UDP port 500 and 4500, and protocol ESP (or AH if set that way). If there is trouble establishing a tunnel, check the firewall logs (Status > System Logs, Firewall tab), and if blocked packets are seen, add appropriate rules to allow that traffic. 

Obviously, I own both boxes so I'll just allow all from my other pfSense's IP.

This post is getting rather long and graphics-heavy, so I'll continue with the pfSense 2 settings in my next post.