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 Tunneling with tinc

VPN tunneling

The Config tab in tinc in pfSense.

tinc is a Virtual Private Network (VPN) daemon that uses VPN tunneling and encryption to create a secure private network between hosts on the Internet. Because the tunnel appears to the IP level network code as a normal network device, there is no need to adapt any existing software. The encrypted tunnels allow VPN sites to share information with each other over the Internet without exposing any information to others. tinc is free software and is licensed under the GNU General Public License (GPL). tinc incorporates the following features:

  • Encryption, authentication and compression
  • Automatic full mesh routing
  • Easy to add nodes to your VPN
  • Ability to bridge ethernet segments to work like a single segment
  • VPN tunneling that runs on many operating systems (Linux, FreeBSD, OpenBSD, NetBSD, MacOS X, Solaris, Windows 2000, Windows XP, Windows Vista and Windows 7/8 supported)

VPN Tunneling with tinc: Installation and Configuration

If you choose to install tinc on any of these platforms, binaries are available on the tinc website, as well as documentation. If you choose to install it under pfSense, installation is as easy as finding the tinc package on the package list after navigating to System -> Packages. Once you have found it, click on the “plus” button to install the package, and on the next screen, press the “Confirm” button to confirm installation. The installation should complete within a few minutes.


Once tinc is installed, there will be a new entry under the “VPN” menu called “tinc”. Before you start to configure tinc for VPN tunneling, it might be a good idea to consider how you want to organize your VPN. For example, what are the nodes running tinc? What IP addresses and subnets do they have? What is the network mask of the entire VPN? Do you need special firewall rules, and do you have do set up masquerading or forwarding rules? Do you want to run tinc in router mode or switch mode? It also helps to have a good general understanding of networks.

VPN tunneling

The Hosts tab in tinc.

If you navigate to VPN -> tinc, there are two tabs: “Config” and “Hosts”. Under the “Config” tab, there are several configuation paramters. The “Name” field allows you to enter a name to identify the tinc daemon, which must be unique for the VPN to which this daemon will connect. The “Local IP” field allows you to enter the IP address of the local tunnel interface (often the same IP as your router’s LAN address). “Local Subnet” allows you to specify the subnet behind the router that should be advertised to the mesh, and “VPN Netmask” defines what traffic is the router to the VPN’s tunnel interface. The “AddressFamily” dropdown allows you to select whether listening and outgoing sockets, are IPv4, IPv6, or whether it depends on the operating system. In the “RSA private key” and “RSA public key” fields, you can specify an RSA private/public key pair. You can also check the “Generate RSA key pair” checkbox to generate a new RSA key pair.

On the “Hosts” tab, you can add new hosts by clicking on the “plus” button. The “Name” field allows you to specify a name, while “Address” is for the IP address and “Subnet” is for the subnet behind the host. The “Connect at startup” check box specifies whether tinc should try to connect to the host when it starts. There is also a field for an RSA public key. There are also several advanced settings in both the “Config” and “Hosts” tab; however, if you configure these basic parameters, you should be ready to use tinc VPN tunneling.


External Links:

The official tinc website

Tinc on Wikipedia (just a stub)

Remote Access Options

remote accessSooner or later, odds are good that you will either want or need the ability to work remotely. Providing remote access must be undertaken very cautiously, because as soon as you allow an employee to connect to the corporate network, you have to some degree extended your network boundary to their workstation. This means your network’s security is now only as good as the security of the remote user’s system or network. In some cases, this borders on no security at all. This is why remote access must only be granted after careful consideration and planning. While the different types of remote access have different levels of security risk, all types of remote access have some common planning and configuration steps.

Remote Access: VPNs

The first step is to determine what type of remote access is appropriate. A virtual private network (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. This generally provides the greatest level of functionality, but also poses the greatest risk. If the remote system is compromised, an attacker is effectively inside your corporate network. While there are steps you can take to mitigate these risks, they may be time-intensive and effort-intensive. To plan, configure and properly secure a VPN solution is the most involved choice of the various remote access solutions you could provide.

Remote Access: Remote Desktop Software

Another option is to provide remote desktop functionality. This would allow a remote user to see and use the desktop of a system at work. A remote desktop acts as if the user is at work, while a VPN acts as if the user’s computer is at work. This type of solution is slightly easier to implement, because you can typically isolate the traffic that needs to be permitted through the firewall to a single TCP port. Many of the same risks exist, however, in that if an attacker manages to gain access to an internal desktop remotely, it is usually easy for them to move information out of the network or otherwise cause mischief. Another key consideration with this type of solution is that you need to have a computer at home and a computer at work. With the VPN option, youonly need to use one system, so if the user has a laptop, it can be used while they work remotely. There are several options for remote desktop functionality: LogMeIn (which is no longer free), TeamViewer (free for home users), and Symantec’s PcAnywhere, to name but a few.


Remote Access: Remote Shell

The last and least functional option is that of a remote shell. Because most users do not operate extensively (or even at all) in a console environment, this type of remote access is generally most suitable for network administration personnel. While it may be impossible for typical users to operate their systems without a GUI, many network tasks and most firewall administration tasks can be permormed with only terminal access. Because the widely-used Telnet protocol sends all data unencrypted, any sensitive tasks should only be performed using a secured protocol such as secure shell (SSH), or Telnet over a Secure Internet Protocol (IPsec) tunnel.

External Links:

VPN at Wikipedia

Wireless Network Security in pfSense

Wireless Network SecurityIn addition to strong encryption from WPA or WPA2 with AES, some users like to employ an additional layer of encryption and authentication before allowing access to network resources. The two most commonly deployed solutions used to ensure wireless network security are captive portal and VPN. These methods may be used whether you use an external access point or use an optional (OPT) interface or an internal wireless card as your access point.

Wireless Network Security: Captive Portal

By enabling captive portal on the interface where your wireless is, you can require authentication before users can access network resources, thus providing an additional layer of wireless network security. In corporate networks, this is often deployed with RADIUS authentication to Microsoft Active Directory so users can use their Active Directory credentials to authenticate while on the wireless network. I covered captive portal configuration in two separate installments: part one and part two.

Wireless Network Security: VPN

Wireless Network Security

Firewall rules for IPsec VPN. “WLAN net” is the network of the wireless interface, and “Wireless IP” is the IP address of the wireless interface. The rules are slightly different for OpenVPN and PPTP.

Adding captive portal provides another layer of authentication, but it does not offer any additional protection from eavesdropping of your wireless traffic. Requiring VPN before allowing access to the internal network and Internet adds yet another layer of authentication as well as an additional layer of encryption for your wireless traffic, and thus improving wireless network security. The configuration for your chosen type of VPN will be no different from a remote access configuration, but you will also need to configure the firewall rules on the pfSense interface to allow only VPN traffic from your wireless clients.

If you choose to allow only IPsec VPN traffic, you need to set up three rules on you wireless interface. Navigate to Rules -> Firewall, and click on the tab for the wireless interface. Press “plus” to add a new rule. For “Protocol”, select ICMP. For “Source”, select the wireless network; for “Destination”, select the wireless interface IP address. Enter a “Description” and leave the other settings unchanged. Press “Save” to save this rule. Press “plus” to create another rule, and keep the wireless network as the source and the wireless interface IP as the destination. Change the “Prototype” to UDP, and set the destination “Port” to 500. Add a description and press “Save” to save the rule. Press “plus” to create a third rule, and again keep the source as the wireless network and the destination as the wireless interface. Do not set a port and set the prototype to ESP. Then press “Save” to save the rule and on the next page press “Apply changes” to apply the changes.


If you want to use OpenVPN instead, keep the ICMP rule the same, but set the port for the UDP rule to 1194. You do not need a rule to pass ESP traffic. If you want to use PPTP, keep the ICMP rule, add a rule to pass TCP traffic on port 1723, and add another rule to pass GRE traffic on all ports. You do not need a rule to pass UDP or ESP traffic.


External Links:

pfSense OpenVPN Tutorial at YouTube

Secure Your Public WiFi Usage with pfSense IPsec Tunnels at Mostly Secure

Ad Links:

pfSense Hardware Requirements

pfSense Hardware RequirementsBefore you set up your pfSense system, you probably want to consider pfSense hardware requirements. The two main factors that will determine your requirements are:

  • Throughput required
  • Features that will be used

If you require less than 10 Mbps of throughput, then even a Pentium I with a 100 MHz CPU will do. If you require greater throughput, the official pfSense website has the following guidelines (they assure us that the guidelines offer a bit of breathing room):

Summary of pfSense Hardware Requirements

pfSense Hardware Requirements
Throughput Minumum CPU Speed Minimum Interface
10-20 Mbps 266 MHz PCI
21-50 Mbps 500 MHz PCI
51-200 Mbps 1 GHz PCI
201-500 Mbps 2 GHz PCI-X or PCI-e
501+ Mbps 3 GHz PCI-X or PCI-e


Virtually all network cards are supported by pfSense, but not all network cards are created equal. Intel Pro 100/1000 NICs have solid driver support in FreeBSD. NICs such as the Realtek 8139, however, do not perform as well and may require slightly more overhead. Moreover, with some NICs, there are some things that may not work properly at all, such as VLANs or promiscuous mode required for bridging. Generally if you are buying NICs for a new deployment, Intel Pros are the most reliable.

In addition to these guidelines, pfSense’s hardware sizing guidance page mentions the following about pfSense features and how they may relate to pfSense hardware requirements:

  • VPN – Heavy use of any VPN services will increase CPU requirements. Encrypting and decrypting traffic is CPU intensive. A CPU’s encrypted throughput is roughly 20 percent of its unencrypted throughput. For example, a 266 MHz CPU will max out around 4 Mbps of IPsec throughput; a 500 MHz CPU can push 10-15 Mbps of IPSec; and relatively new server hardware deployments (Xeon 800 FSB) are pushing over 100 Mbps with plenty of capacity to spare. Encryption cards can, however, reduce CPU requirements. Check the FreeBSD hardware compatibility list (HCL) before making a purchase, but Soekris VPN-1401 seems to be well-supported. In addition, you may have better luck by switching protocols. OpenVPN, for example, requires less CPU usage than L2TP/IPSec. I am not sure how well PPTP competes with OpenVPN, but presumably it is less CPU intensive, if for no other reason than the fact that it only offers 128-bit encryption versus 256 bits for OpenVPN. As always, the most recent pfSense build will likely provide the best performance. The number of connections is not as significant as the overall throughput required.
  • Captive portal – While the primary concern is typically throughput, environments with hundreds of simultaneous captive portal users will require slightly more CPU power than otherwise, thus increasing the pfSense hardware requirements.
  • Large state tables – State table entries require about 1 KB of RAM each. The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state stables with hundreds of thousands of connections, you will want to ensure adequate RAM is available.
  • Packages – Some of the packages require more RAM; Snort and ntop are two that should not be installed on a system with less than 512 MB RAM. Also, the Squid package is used for caching web content and requires extensive use of a hard disk with a large amount of storage. It is not for use with an embedded installation where writes to the compact flash card are kept to a minimum.


To show how these pfSense hardware requirements work in practice, let’s assume we want to set up a pfSense box for a small office. The office has a 50 Mbps net connection; we want to anticipate future use, but we don’t anticipate the office getting a connection faster than 100 Mbps in the forseable future. We also anticipate making use of VPNs for remote connections to the office, but we don’t plan on having more than a few VPN connections at any given time. Of the packages available, we opt to install Snort. From this information, we can determine our minimum hardware requirements:

  • 1 GHz CPU
  • 512 MB RAM (1 GB recommended)
  • Unencrypted throughput of 50 Mbps; unencrypted throughput of 10 Mbps
  • 100 Mbps network interface cards (1 Gbps recommended)

If we want to have a failover for the firewall, our requirements would include a second machine to be used as a failover. Keep in mind that the firewall’s throughput is only a bottleneck for traffic passing through it. Traffic to and from the Internet from the LAN and the DMZ meet that requirement, as does traffic between the LAN and the DMZ. Traffic between two systems on the LAN, however, or two systems on the DMZ would not be affected.
This is my take on minimum pfSense hardware requirements, but those of you who have experience in deploying pfSense firewalls may have a different take on this. If so, feel free to add your own comments on this subject.

External Links:

pfSense Hardware Requirements and Sizing Guidance at pfsense.org

VPN Protocol Comparison List – provides some guidance as to overhead for the different protocols

How to speed up IPSec, hardware encryption devices? at forum.pfsense.org

SSH Server Configuration in pfSense

SSH

Enabling SSH access in pfSense 2.0.

For today’s article, I decided to cover something I probably should have covered earlier on: how to enable Secure Shell (SSH) login in pfSense 2.0. You may never have occasion to access your pfSense box remotely outside of the web GUI, but enabling the SSH server is still a good idea just in case you do.

Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers that connects via a secure channel over an insecure network, a sever and a client. Typically SSH is used for access to shell accounts on Unixoid operating systems, but it can also be used in a similar fashion for accounts on Windows. It was designed as a replacement for Telnet and other insecure remote shell protocols such as the BSD rsh and rexec protocols, which send information – including passwords – in plain text, thus rendering them vulnerable to interception and disclosure. The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network.


Configuring the SSH Server

To enable the Secure Shell (SSH) service in pfSense, navigate to System -> Advanced, and scroll down to the section labeled “Secure Shell“. Check the “Enable Secure Shell” check box to enable SSH. You will be prompted for a username and password when you connect. You can use the same credentials that you use to connect to the web GUI. But if you check “Disable password login for Secure Shell“, you can use your RSA keys instead. At “SSH port“, leave the edit box blank to use the default port, or type in a different port to use a different one. If you are not going to allow SSH access to your pfSense box from the Internet, you can probably leave the default unchanged; otherwise, it is probably a good idea to choose a port a hacker is unlikely to guess, and even then, it is advisable to do any remote (i.e., from outside the network) administration through a VPN. Finally, press the “Save” button to save the changes and the pfSense SSH service will be started.

Using RSA Keys for SSH Login

SSH

PuTTYGen in action under Windows.

Using RSA keys is one way to secure client/server connections between the client and the SSH server. In order to utilize RSA keys, you must first generate a public-private key pair using a tool such as ssh-keygen on a Linux-based system or a Mac, or a tool such as PuTTYGen on a Windows-based system. To use ssh-keygen, simply open a terminal, run ssh-keygen, and save the key (you can also specify a pass code). To use PuTTYGen, open it and press the “Generate” button to generate a public/private key pair. You can enter a passphrase in the appropriate edit box, and press “Save private key” to save the private key. You can copy and paste the public key from the text box at the top of the application’s dialog box.

SSH

Pasting a public key in the pfSense User Manager.

Once you have a public/private key pair, you need to make sure that “Disable password login for Secure Shell” is checked in the Secure Shell settings at System -> Advanced. Then navigate to System -> User Manager, and click on the “e” next to the admin listing in the table to edit settings for the admin account. Scroll down to “Authorized keys” and check the “Click to paste an authorized key” check box. Now you can paste the public key into the text box. Press the “Save” button to save the changes.

Now, when you connect to pfSense using an SSH client, you will not be prompted for a password. Instead, your client must have the private key of the public/private key pair generated earlier in order to be authenticated.


External Links:

How to Enable SSH Access at doc.pfsense.org

The SSH lockout table at doc.pfsense.org

Forum posting on safely adding SSH users to pfSense at serverfault.com

pfSense Setup: Part Three (WAN and LAN Settings)

In pfSense Setup: Part Two,  I covered General Settings within the pfSense web GUI. In this part, I cover configuring the WAN and LAN interfaces. There are a number of different options here; fortunately, pfSense makes the job easy on us by creating reasonable defaults. From the pfSense web GUI menu, go to Interfaces -> WAN.

pfSense Setup: WAN Interface Settings

WAN

The WAN settings page in the pfSense web GUI.

The WAN interface provides your connection to the Internet. To access the WAN, you will need a properly-configured WAN interface and an Internet connection. Typically your Internet connection will be through a cable modem provided by your Internet service provider (ISP), but pfSense will support other connection methods as well.

To configure the WAN interface, browse to Interfaces | WAN. Under “General Configuration”, check Enable Interface. You can change the description of the interface (Description).

The next item is “Type”. Here you can choose the interface type. “Static” requires you to type in the WAN interface IP address. “DHCP” gets the IP address from the ISP’s DHCP server, and is probably what you want to select. “PPP” stands for Point-to-Point Protocol, a protocol used for dialup modem connects as well as T-carrier, E-carrier connections, SONET and SDH connections and higher bitrate optical connections. “PPPoE” stands for Point-to-Point Protocol over Ethernet and is used by a number of DSL providers. “PPTP” stands for Point-to-Point Tunneling Protocol and is a method for implementing virtual private networks (VPNs); unless your WAN interface is a VPN you won’t want to choose this option. “L2TP” stands for Layer 2 Tunneling Protocol, a tunneling protocol also used with VPNs.

The next option is MAC address. Typing in a MAC address here allows you to “spoof” a MAC address. The DHCP servers of ISPs assign IP addresses based on MAC addresses. But they have no way of verifying a MAC address, so by typing a different MAC address, you can “force” your ISP’s DHCP server to give you another IP address. Unless you want to spoof your MAC address, you can leave this field blank. MTU stands for maximum transmission unit. Larger MTUs bring greater efficiency but also greater latency. This should probably be left unchanged. MSS stands for maximum segment size, and specifies the largest amount of data pfSense can receive in a single TCP segment. This also should likely be left unchanged.


The next section is different depending on what you selected for the interface type. If you selected “DHCP”, the options will be “Hostname” and “Alias IP Address”. Hostname can be left blank unless your ISP requires it for client identification, and Alias IP address can also be left blank unless the ISP’s DHCP client needs an alias IP address.

The next section is “Private Networks”. Checking “Block private networks” ensures that 10.x.x.x, 172.16.x.x, and 192.168.x.x addresses, as well as loopback addresses (127.x.x.x) are non-routable. This should be left checked under most circumstances. “Block bogon networks” blocks traffic from IP addresses either reserved or not yet assigned by IANA. This should be left checked as well, for obvious reasons.

Save the options and move on to Interfaces -> LAN.

pfSense Setup: LAN Interface Settings

WAN

The LAN settings page in the pfSense web GUI.

Under “General Configuration”, “Enable Interface” should be checked, since unchecking it will prevent the local network from connecting to the router. “Description” allows you to type in a description of the interface.

“Type” allows you to choose an interface type. See the section on WAN settings for an explanation of each of the options. “MAC address” allows you to type in a different MAC address in order to do MAC address spoofing. Again, see the section on WAN interface settings for a more detailed explanation. “MTU” and “MSS” are also explained under WAN settings. “Speed and duplex” allows you to explicitly set speed and duplex mode for the interface; pfSense should autodetect this, so this option should be left unchanged.

If you selected “Static” for the interface, there should be a “Static IP Configuration” section with two options: “IP address” and “Gateway”. With “IP address”, you can change the IP address of the LAN interface (it defaults to 192.168.1.1).

The next section is “Private networks”. The two options are “Block private networks” and “Block bogon networks”. See the section on configuring the WAN interface for detailed explanations of these options.

That does it for WAN and LAN settings. In pfSense Setup: Part Four, I will take a look at setting up an optional interface.


The Rest of the Guide:

Part One (installation from LiveCD)

Part Two (configuration using the web GUI)

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy