IP sec

What is IPsec IPsec (IP security) is a standard for providing security to IP protocols via encryption and/or authentication, typically employing both. Its use in pfSense is for Virtual Private Networks (VPN's).

There are two types of IPsec VPN capabilities in pfSense, site to site and remote access.

Site to Site VPN Explained

While site to site VPN's are a good solution in many cases, private WAN links also have their benefits. IPsec adds processing overhead, and the Internet has far greater latency than a private network, so VPN connections are typically slower (while maybe not throughput-wise, they at least have much higher latency). A point to point T1 typically has latency of around 4-8 ms, while a typical VPN connection will be 30-80+ ms depending on the number of hops on the Internet between the two VPN endpoints.

When deploying VPN's, you should stay with the same ISP for all sites if possible, or at a minimum, stay with ISP's that use the same backbone provider. Geographic proximity usually has no relation to Internet proximity. A server in the same city as you but on a different Internet-backbone provider could be as far away from you in Internet distance (hops) as a server on the other side of the continent. This difference in Internet proximity can make the difference between a VPN with 30 ms latency and one with 80+ ms latency.

Remote Access IPsec VPN

pfSense provides several means of remote access VPN, IPsec, OpenVPN, and PPTP (L2TP will also be available in 2.0). pfSense's mobile IPsec functionality has some serious limitations that could hinder its practicality for some deployments. pfSense will support NAT-Traversal (NAT-T) for IPsec only starting with version 2.0, which means if any of your client machines are behind NAT, IPsec VPN will not work unless you are using that version or newer. This may eliminate older versions as a possibility for most environments, since remote users will almost always need access from behind NAT. Many home networks use a NAT router of some sort, as do most hot spot locations, hotel networks, etc.

One good use of the pfSense IPsec client VPN capabilities is to secure all traffic sent by hosts on a wireless network or other untrusted network. This will be described later in this chapter.

Remote users running Windows can connect back to your pfSense router using IPsec client software, such as the Shrew Soft VPN Client. See this article for details on configuring a road warrior/mobile tunnel setup with the Shrew Soft client.

Prerequisites

Before getting started, you need to take care of the following.

1. Your pfSense must be setup and working properly for your network environment.
2. Both locations must be using non-overlapping LAN IP subnets.
   1. For example, if both sites are using 192.168.1.0/24 on the LAN, no site to site VPN will work. This is not a limitation in pfSense, it's basic IP routing. When any host on either of your networks tries to communicate with 192.168.1.0/24, it will consider that host to be on its local LAN and the packets will never reach pfSense to be passed over the VPN connection. Similarly, if one site is using, for example, 192.168.0.0/16 and one using 192.168.1.0/24, these subnets are also overlapping and a site to site VPN will not work. Keep in mind the more networks you link together the more important this basic fact becomes. Do not use unnecessarily large subnet masks. If you setup your LAN as 10.0.0.0/8, but only have 100 hosts on it, you're unnecessarily limiting your ability to add VPN networks anywhere in the 10.x.x.x space.
3. If pfSense is not the default gateway on the LAN where it is installed, you must add static routes to whatever system is the default gateway, pointing the remote VPN subnet to the LAN IP of pfSense. Less desirable, but also functional, would be to add static/persistent routes to the client PCs who need access to the VPN.
4. You will need to either control or be in contact with the person who does control the other VPN concentrator. If it is another pfSense system, then share this document with the other administrator. If it isn't then have them consult the documentation that came with the IPsec device they are using.
5. Host and application level security become more important when connecting multiple networks, how much depending on how much you trust the other network. If a system on the remote network is compromised by an attacker, he could easily hop over the VPN to attack your systems without any firewall protection, if you have allowed all traffic to pass on the VPN tunnel.
6. Pay attention to what you are doing! If you have a VPN to your office, and a VPN to your friend's home network, your friend can now hop over to your company's network from your network. Or, if your friend gets infected with a worm, it could then infect your machines and continue to propagate over the VPN connection to your office. Most companies would probably fire you if your friend was caught on their network. Best bet here is if you have a site to site VPN into your network at work, do not connect with friends, or use one network and firewall for accessing work and one for accessing your friend's network.

Ok, now that we have the basics let's get started on the firewall settings.

Configuring the VPN Tunnel

First, log into the pfSense router for your network and click VPN > IPsec

Next, click the '+' icon to add a new IPsec tunnel

The settings on this screen will contain all of the information about the tunnel, and the networks being connected.

The first area is the one used to set basic tunnel settings, and define what network ranges will use this IPsec tunnel.

If the information is incorrect in this section, the tunnel will likely fail to successfully negotiate phase 1 and/or phase 2.

1. Mode: This setting cannot be changed, and states that a tunnel is being built rather than a mobile connection.
2. Disabled: This is an "on / off" button. If you need to disable the tunnel for any reason, simply check this option and click save at the bottom of the page, then apply. When tunnel is needed again, uncheck it and save/apply once more.
3. Interface: This determines which part of the network will be the termination point (end point) for the IPsec tunnel. If the tunnel will be connecting to a remote server, then WAN is likely the desired setting.
4. DPD interval: Enter a value here to enable Dead Peer Detection (e.g. 60 seconds). This will help fully reestablish tunnel when the other side has a problem.
5. Local subnet: This defines which subnet or host can be accessed from the other side of the VPN tunnel. The easiest thing to do is to set this to "LAN subnet". This means the entire LAN will be accessible from the remote network. IMPORTANT: The other end of the tunnel has this same field, except on the far side it is "Remote Subnet". Ensure that the other end is set exactly the same. For example, if "Single host" is chosen in this section and the IP address of a host was entered, the other side would need to set that host in the "Remote Subnet" field.
6. Remote Subnet: This defines which subnet or host to be accessed on the other end of the tunnel. As mentioned in the previous item, it is paramount that this is set this exactly like the other end's "local subnet" section. If not, phase 2 of the VPN connection will fail and traffic will not pass from one VPN segment to the other.
7. Remote Gateway: This is the IP Address for the router to which the tunnel will be established. This is most likely the WAN IP of the remote system. As of pfSense 1.2.3, a hostname may also be used in this field. By entering a dyndns hostname, a tunnel can be defined between two systems that both have dynamic IPs.
8. Description: It is a good practice to leave notes about the purpose of a tunnel. Enter something about what this VPN tunnel is used for, or about the remote end of the tunnel. This will serve as a reminder for anyone managing the router (present or future) as to who or what will be using the tunnel.

All of the basics for routing have been established. Now for phase 1 of the VPN authentication process.

The trick here, as for all other parts of VPN configuration, is to make sure that both VPN servers have EXACTLY THE SAME SETTINGS for of these fieldd, with only a few exceptions to that rule: Both sides will have different a Identifier and Remote Gateway. Subnet definitions, timeouts, encryption settings, etc, all need to match.

1. Negotiation mode: This is the type of authentication security that will be used. Unless need 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)
2. My identifier: This is the key to probably 90% of the email on the list where people seem to not get the VPN tunnel up, or want to know how to do this with dynamic IP addresses, etc. Very simple, set the identifier to something that isn't going to change. So if this is left as "My IP address" (This will be the IP address of the "interface" listed in the first section.) then make sure that IP is static and persistent. If there is a DHCP assigned address then using "User FQDN" or "Domain Name" instead would be better. This is purely cosmetic, so you do not need to own a domain that is put in here. Make it pfsense1.local, sitea.example.com, siteb.my.vpn, or whatever is wanted.
3. Encryption Algorithm: 3DES is the world de facto standard. If the other side is another pfSense router, or a system that will support it, change this to Blowfish. It is about twice as fast! Now of course, if the other end is a VPN device that only supports DES (NOT 3DES) then downgrade and hope no one decrypts the key exchange. Make sure both sides of the VPN tunnel are using the same encryption algorithm!.
4. Hash Algorithm: this is the hash used for checksum. SHA1 is the new up and comer and it is more reliable than MD5. However, some devices may only support MD5. Again make sure the same setting are in use on both ends of the tunnel, and if SHA1 is available on both sides, by all means use it.
5. DH Key Group: Most systems will support at least up to 1024 bit. This is a good place to stick to, going with more will eat up more resources and less makes the tunnel less-secure.
6. Lifetime: This field is far more important then it appears. This lifetime, as opposed to the one in phase 2, is how long this router will wait for phase 1 to be completed. 28800 is a good suggested value for this field.
7. Authentication Method: Most people will use Pre-Shared Key, but pfSense also supports using an RSA Signature.
8. Pre-Shared Key: This key must be exactly the same on both VPN routers. It is case sensitive, and it does support special characters. Using both is a good idea, such as: f00m0nk3y@BubbaLand. The longer the key, the better. Think of this like a "password" for the tunnel. Since this only gets entered once on each side and there is no need to remember it, it is better to make this as long and complex as possible.
9. Certificate: If using an RSA Signature, paste an X.509 certificate in PEM format for this router here. Leave this blank if using a Pre-Shared Key.
10. Key: If using an RSA Signature, paste an RSA private key in PEM format here. Leave this blank if using a Pre-Shared Key.
11. Peer Certificate: If using an RSA Signature, Paste the peer X.509 certificate in PEM format here. Leave this blank if the CA certificate will only be used for identity validation. Also leave this blank if using a Pre-Shared Key.

If you managed to coordinate and get both VPN systems set the same all should be good for phase 1. Now to tackle phase 2.

Phase 2 is what builds the actual tunnel, sets the protocol to use, and sets the length of time to keep the tunnel up when there is no traffic on it.

1. Protocol: 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.
2. Encryption algorithms: As before in phase 1, make sure the algorithm is set exactly as it is set on the other VPN router. Several can be used if desired; Everything selected is available for use. That said, it is recommended to only check the one that will be used. Use AES-128 (Rijndael) if available.
3. Hash algorithms: Also as in phase 1 make sure the selected hash matches the one on the other end. And as with the previous step, don't add things that are not needed. SHA1 is a good setting, but like phase 1, some routers may only support MD5.
4. PFS key group: This works similarly to the DH group in phase 1. 1024 bit is a good setting, the default is off.
5. 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 day (86400) is a good setting.
6. Click Save
7. Click Apply Changes

Add Firewall Rules

After building the tunnel, you will need to add firewall rules (Firewall > Rules, IPsec tab) that govern what traffic is allowed to pass on your VPN tunnels. At the very least, you will need an allow all rule (Pass protocol any, src host any, dst host any). That said, you will likely want more restrictive rules to enforce proper network security protocols.

If you are too lenient with the firewall rules, then any host on the remote side will be able to directly contact any host on your network as if they were on the same LAN.

You may also need to check your WAN rules to ensure that the traffic from the remote pfSense host is allowed. IPsec uses UDP port 500, and protocol ESP (or AH if set that way). If you have 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.

What if your pfSense isn't the main Internet Firewall?

In some cases you have a firewall or router sitting in front of pfSense. If this is the case you will need to port forward ESP and UDP 500 to pfSense. The outside router must be able to properly handle NAT of this traffic, and some do not.

This may introduce routing difficulties on your internal network. You can find details on this in the pfSense book