IPsec VPN Configuration in pfSense: Part One

IPsec VPN

Phase 1 IPsec configuration in pfSense 2.2.4.

In the previous article, we covered how to set up a PPTP VPN connection in pfSense, and how to connect to it in Mint Linux. Since PPTP relies on MS-CHAPv2, which has been compromised, we probably want to use another method if security is paramount. In this article, we will cover setting up an IPsec tunnel with pfSense and connecting to it with Mint Linux.

IPsec VPN Configuration: Phase 1

First we need to set up the IPsec tunnel in pfSense. Navigate to VPN -> IPsec and click on the plus button on on the lower right to add a new tunnel. Under General information, there is an entry for Interface, where we select the interface for the local endpoint of the tunnel. Since our end user will be connecting remotely, the local endpoint should be WAN. The next entry is Remote Gateway, where we enter the IP address or host name of the remote gateway. Enter a brief description and scroll down to the Phase 1 proposal (Authentication) section. At Pre-Shared Key, you need to enter a key (PSK), which will essentially be the tunnel’s password. Whether you alter the Phase 1 proposal (Algorithms) settings or not, take note of the settings, as we will need them for future reference. Press the save button at the bottom to save the Phase 1 configuration. On the next page, press the Apply changes button to commit changes.

IPsec VPN

Phase 2 IPsec configuration.

IPsec VPN Configuration: Phase 2

Now there should be a new entry in the IPsec table for the new Phase 1 configuration. Click on the big plus button underneath the entry you just created to initiate Phase 2 configuration. This section should expand, revealing an empty table for Phase 2 settings. Click on the (smaller) plus button to the right of the table to bring up the Phase 2 settings page. For Mode, you can select whichever method you prefer, but note that whoever connects will have to use the same method. For Local Network, enter the network or address to which you want to give the VPN user access (probably LAN net). For Remote Network, enter the address of the remote end of the VPN tunnel. Enter a brief description. In the Phase 2 proposal section (SA/Key Exchange), set the protocol and encryption options, again taking note of them for future reference (AES-256 is the commonly used standard). When you are done, press the Save button at the bottom of the page. Press the Apply changes button on the next page to commit changes. Finally, check the Enable IPsec check box on the main IPsec page and press the Save button.


Now that Phase 1 and Phase 2 configuration are complete, all that remains is to create a firewall rule for IPsec traffic. Navigate to Firewall -> Rules. There should be a new tab for IPsec; click on it. There may already be a rule there allowing traffic to pass to whatever network or address you specified in the Phase 2 configuration. If not, then create one now by pressing the one of the plus buttons on this page. Most of the default settings can be kept, but set Destination to the network or address specified in Local Network in the Phase 2 configuration. For Destination port range, specify any. Add a brief description, and press the Save button. On the next page, press the Apply changes button to commit these changes.

In part two of this article, we will cover connecting to the VPN tunnel from the remote node.

External Links:

IPsec on Wikipedia

pfSense IPsec configuration information from the official pfSense site

VPN Access Strategies

VPN accessA virtual private network (VPN) is exactly what it sounds like: the network connection you create is virtual, because you can use it over an otherwise public network. Basically, you take two endpoints for the VPN tunnel, and all traffic between these two endpoints will be encrypted so that the data being transmitted is private and unreadable to the system in between. Different VPN solutions use different protocols and encryption algorithms to accomplish this level of privacy. VPNs tend to be protocol independent, at least to some degree, in that the VPN configuration is not on a per-port basis. Rather, once you have established the VPN tunnel, all applicable traffic will be routed across the tunnel, effectively extending the boundaries of your internal network to include the remote host. In this article, we will examine some of the issues involved in implementing VPN access.

VPN Access: Network Design

One of your first considerations when planning to provide for VPN access is the network design. Because the VPN tunnel needs two endpoints, one will be the remote workstation. The other will be a specially configured device for that purpose. This is generally called a VPN concentrator, because it acts as a common endpoint for multiple VPN tunnels. [As noted previously in this blog, Soekris makes affordable VPN cards that offload the CPU of the the computing intensive tasks of encryption and compression.] The remote system will effectively be using the concentrator as a gateway into the internal network; as such the placement of the concentrator is important: in a highly secured environment, the concentrator is placed in a DMZ sandwiched between two firewalls, one firewall facing the Internet, and the other facing internally. While this type of arrangement is the most secure, it takes more hardware to implement.


Another way to place the VPN concentrator inside a DMZ is to use an additional interface on the firewall as the DMZ in a “one-legged” configuration. This saves you having to implement an additional firewall, but still provides some isolation between the concentrator and the rest of the internal network. If an attacker compromised a remote host who was VPNed into the concentrator or compromised the concentrator itself, they would still have a firewall between them and the internal network. The least preferable option is to place the concentrator inside the internal network. With this type of design, if the concentrator is compromised, the attacker would have full access to the internal network, with no firewalls to inhibit their activities. With any of these designs, you will have to permit the required ports through the firewall and forward them to your VPN concentrator in order to ensure VPN access.

VPN Access: Protocols

Another consideration in providing VPN access is the type of VPN protocol you want to use. IPsec is still the most widely deployed VPN technology for good reason. One is interoperability. As a widely used and tested standard, IPsec will work with virtually any modern firewall and operating system. The disadvantage of IPsec is that it can sometimes be difficult to configure properly, and there is zero margin for error on the configuration. Both ends have to se the same parameters for encryptions, hashing, and so forth, or the tunnel cannot be established. SSL is an increasingly popular choice for VPNs, largely because of its simplicity to implement.

Once you have chosen a design and VPN technology, you need to consider the administrative ramifications of offering remote access. Some level of training will be required. At the very least, they may require training to use the VPN software. It is a good idea to educate your users on good security habits as well. A determination will also need to be made as to whether remote users are allowed to use their own personal computers and/or laptops, or if they must use a company-provided computer for remote access. The former option carries with it many risks. When a remote user connects their personal computer to the corporate network, they may have spyware, a virus, or any number or potentially damaging conditions present on their system. Due to the fact that you probably do not have any administrative access to their systems, you may have no way to secure the personal systems even if you wanted. This is why most companies require that only corporate resources be allowed to connect to the company network.

VPN Access: Hardware

One last consideration for VPN access is hardware selection. Normal workplace desktop applications place very little strain on even a remotely modern processor. The same is not true when it comes to VPN connections. A single VPN connection requires little overhead and rarely impacts the remote user’s system unless it is especially underpowered. For the VPN concentrator, however, it will handle the encryption and decryption of multiple connections, in addition to managing the volume of network data that will be accessed through it. For this reason, if you anticipate more than just a couple of VPN connections to be used simultaneously, you will want to test and evaluate your hardware needs.


Internal Links:

pfSense VPN: Part One

pfSense VPN: Part Two

pfSense VPN: Part Three (PPTP)

External Links:

An Overview of VPN Concentrators at YouTube (from CompTIA’s Network+ certification training)

How the VPN Concentrator Works at networkingtechnicalsupport.blogspot.com

Advanced Miscellaneous Options in pfSense: Part Two

In the previous article, I covered the proxy support, load balancing, and power saving options in the advanced pfSense settings. In this article, I will cover the remaining options found by navigating to System -> Advanced and clicking on the “Miscellaneous” tab.

Crypto Acceleration

Advanced Miscellaneous

Other advanced miscellaneous options in pfSense.

The first option that will be covered is found under the “glxsb Crypto Acceleration” heading. Check on the “Use glxsb” check box if you want to enable AMD Geode’s glxsb acceleration. Cryptographic acceleration is available on several platforms, typically on embedded boards such as ALIX and Soekris, but also with add-on cards such as those from Hifn are also supported. Any crypto accelerator supported by FreeBSD will work. Boards utilizing the AMD Geode platform typically have the “AMD Geode LX Security Block” which supports certain encryption types. The AMD Geode LX Security Block will accelerate some cryptographic functions on systems which have the chip. If you have a cryptographic acceleration card with the Geode LX processor, you can check this box. If you have a Hifn cryptographic card, however, do not use this option, as it will take precedence and the Hifn card will not be used. If you do not have a glxsb chip in your system, this option will have no effect. To unload the module, uncheck this option and then reboot.


IPsec Options

Under the “IP Security” heading, there are several settings pertaining to IPsec VPN tunnels. The first setting is the “Prefer older IPsec SAs” check box. In an IPSec VPN tunnel, IPsec secured links are defined in terms of security associations (SAs). Each SA is defined for a single unidirectional flow of data, and usually from one single point to another, covering traffic distinguishable by some unique selector. All traffic flowing over a single SA is treated the same. By default, if several security associations match, the newest one is preferred if it is at least 30 seconds old. Selecting this option causes pfSense to always prefer old SAs over newer ones.

The next option is the “Start racoon in debug mode” check box. Racoon is an Internet Key Exchange (IKE) daemon for automatically keying IPsec connections, to establish security associations with other hosts. Checking this box launches racoon in debug mode so that more verbose logs will be generated to aid in troubleshooting. Changing this setting will restart racoon, which could interrupt VPN connections. The last setting under this heading is “Enable MSS clamping on VPN traffic“. Checking this box allows you to adjust the maximum segment size (MSS) on TCP flows over VPN by typing a different segment size into the edit box below the check box. This helps overcome problems with PMTUD on IPsec VPN links and therefore is sometimes advantageous. If left blank, the MSS remains at the default value of 1400 bytes.


Other Options

The next heading is “Schedules” and the only option is the “Schedule States” check box. By default, schedules clear the states of existing connections when the expiry time has come. Checking this box overrides that behavior by not clearing states for existing connections. The final heading on this page is “Gateway Monitoring”, and has one option: the “States” check box. By default, the monitoring processs will flush states for a gateway that goes down. Checking this box overrides this behavior by not clearing states for existing connections.

Other articles in this series:

webConfigurator options in pfSense

Admin Access Options in pfSense

Firewall Advanced Options in pfSense

NAT and Firewall Options in pfSense

Advanced Networking Options in pfSense

Advanced Miscellaneous Options in pfSense

External Links:

Are cryptographic accelerators supported at doc.pfsense.org

IPsec for Dummies at people.freebsd.org

The Racoon man page

pfSense VPN: Part One

pfSense VPN

Configuring an IPsec VPN tunnel in pfSense 2.0.

Virtual Private Networking (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security and management policies of the private network, and is accomplished by establishing a virtual point-to-point connection with another computer. This is done through dedicated connections, encryption, or a combination of the two. Most router/firewalls support VPN, and this article describes some of the pfSense VPN options.


There are a variety of VPN services available, and pfSense has four of the most popular implementations built right in: IPsec, L2TP, OpenVPN, and PPTP. OpenVPN is emerging as the standard VPN protocol, but OpenVPN support is not built into Windows – you’ll have to download the client software. IPsec is also a popular VPN implementation. PPTP and L2TP, on the other hand, are losing ground to OpenVPN, but are still popular and are supported by most major operating systems.

pfSense VPN: IPsec

pfSense VPN

Setting up a firewall rule to allow IPsec traffic to the LAN.

In many cases, IPsec is the preferred method for network-to-network connections. IPsec (Internet Protocol Security) is a technology protocol suite for securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. Setting up an IPsec connection in pfSense is easy. Browse to VPN -> IPsec. If the “Tunnels” tab is not already selected, select it. Click the “Plus” button to create an IPsec tunnel. Leave “Disable this phase 1 entry” unchecked and keep the interface as “WAN“. At “Remote Gateway“, enter the public IP address or host name of the remote gateway. At “Pre-Shared Key“, input your pre-shared key string. Now, click on “Save” to save the changes, click on “Enable IPsec“, and click on the “Save” button again. Click on “Apply changes” if necessary.


In order for IPsec traffic to pass through to the LAN, we need to create a new rule. Browse to Firewall -> Rules and select the IPsec tab. Click on the “Plus” button to add a new firewall rule. At “Destination“, set the destination to the LAN subnet, and at “Destination port“, set the destination port to “any“. Add a description at “Description” if you want, and click on “Save” to save changes. Click on “Apply changes” if necessary. This completes the set up of a pfSense VPN tunnel with IPsec.

In the next article, I will cover using VPN with the L2TP and OpenVPN protocols. Part three will cover the PPTP protocol.

External Links:

Setting up an IPsec VPN Link at doc.pfsense.org

© 2013 David Zientara. All rights reserved. Privacy Policy