VPN Capability IPSec

From PFSenseDocs

Jump to: navigation, search
This article is part of the HOWTO series.

Previous page Contents Next Page

Contents


[edit]

Summary

This chapter will go over configuring a site to site VPN link between two pfSenses, and will discuss how to configure site to site links with third party IPsec-compliant devices. The Example VPN Configurations chapter goes over, in detail, how to configure site to site IPsec links with some third party IPsec devices. If you have gotten pfSense working in a site to site IPsec configuration with some third party IPsec device, we would appreciate if you could put together a short write up of how you got it configured, preferably with screenshots where applicable.

[edit]

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.

[edit]

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.

[edit]

Remote Access IPsec VPN

pfSense provides two means of remote access VPN, PPTP and IPsec (with OpenVPN available in beta versions only for now). pfSense's mobile IPsec functionality has some serious limitations that hinder its practicality for many deployments. pfSense does not support NAT-Traversal (NAT-T) for IPsec, which means if any of your client machines are behind NAT, IPsec VPN will not work. This alone eliminates it 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.

FIXME - A second limitation is the lack of any really good, free IPsec VPN clients for Windows. Most of your remote users will likely be Windows laptop users, so this is another major hindrance.

[edit]

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.
  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. The VPN tunnel will not respond to firewall rules at the time of this writing, so you will not be able to limit which hosts can be accessed by users across the VPN connection. If a worm would get into the network you are connected to via VPN, it could easily spread to your 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.
  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.

[edit]

Configuring the VPN Tunnel

Log into your pfSense and click IPsec , under VPN.

Ok now we need to add a VPN connection, to do this click on the icon.

You will be presented with a great form, I will be pasting screen shots of each section as we discuss it.

The first area is the one you use to establish what network ranges will use this IPSEC tunnel.

This is the first set of fields that we need to concentrate on. Later, when testing your tunnel, you can actually fail to establish level 2 connection if this data is incorrect. I will note what to pay particular attention to as we go along.

  1. Mode, this is a hard set option and frankly you don’t need to change it (nor can you.)
  2. Disabled, this is a great “on / off” button if you need to disable the tunnel for what ever reason. Simply select the edit or from the main VPN: IPsec window and click this checkbox element, then select apply at the bottom of the page. When you need the tunnel again, reverse the process.
  3. Interface, this is how you determine which part of your network will be the termination point (end point) for the VPN Tunnel. If you are connecting to a remote server, then WAN is your option.
  4. Local subnet. This is where you can set which parts, hosts, or the entire LAN can be accessed from the other side of the VPN tunnel. The easiest thing to do is to set the LAN subnet as the option; this means your entire LAN will be accessible from the remote network. IMPORTANT: The other end of the tunnel has this same field, well it probably has 99% of these fields actually, make sure the other end is set exactly as you set this end. E.g. if you said “Single host” in this section and entered the IP address of that host, the other person would set that host in his “Remote Subnet” field. The same goes for you, and with that mentioned we move to the next field.
  5. Remote Subnet. This is more than just labeling which hosts and / or host you want to access on the other network, as mentioned in item 4 it is paramount that you set this exactly like the other end’s “local subnet” section. If not, level 2 of the VPN connection will fail and traffic will not pass from one VPN segment to the other.
  6. Description: It is a good practice to always leave notes about why you are doing something. I suggest you enter something about what this VPN tunnel is used for, or about the remote end of the tunnel to remind yourself who/what it is.

Ok all the basic for the routing have been established. Now we move on to phase 1 of the VPN authentication process.

Okay the easy part of the VPN tunnel. The trick here, and even in phase 2, is to make sure that both VPN servers have EXACTLY THE SAME SETTINGS for all of these fields. Well okay, they will have different “My identifier” but make darn sure that they know each others names… more on that later.

  1. Negotiation mode: This is the type of authentication security that will be used. Unless you are under close watch by someone with paranormal like craziness, just leave this as aggressive. It is indeed far faster and will insure that your 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 your identifier to something that isn’t going to change. So if you leave it as My IP address (* This will be the IP address of the “interface” you listed in the first section. *) then make sure that IP is static and persistent. If you use a DHCP assigned address then I would suggest using domain name instead This is because domain name can be completely your own even if you do not own the domain name. Make yours sexylovemonkey.com just for fun. ;)
  3. Encryption Algorithm: 3DES is the world de facto… if you are connecting to another pfSense, or a system that will support it, change this to Blowfish. It is about twice as fast! Now of course, if you are trying to connect to a VPN device that only supports DES then you will need to downgrade and hope no one decrypts your key exchange. MAKE SURE BOTH VPN DEVICES ARE USING THE SAME ENCRYPTION ALGORITHM.
  4. Hash Algorithm: this is the hash used for checksum. MD5 is a good choice, SHA1 is the new up and comer and it is more reliable than MD5. Again make sure you are using the same setting as the other end of the tunnel, and if you can use SHA1 go for 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 your 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 your end will wait for phase 1 to be completed. I suggest using 28800 in this field.
  7. Pre-Shared Key: Contrary to some suggestions this key must be exactly the same on both VPN routers. It is case sensitive, and it does support special characters. I suggest using both. E.x. f00m0nk3y@BubbaLand

Okay if you managed to coordinate and get both VPN systems set the same all should be good for phase 1. We really don’t want to stop here, so let’s go right into 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 on what most VPN systems use as a transport protocol. I suggest leaving this as is. Note: The system should auto generate a firewall rule for you to allow ESP or AH to the endpoint of the VPN. We will check this later, if it does not you will need to make a firewall rule allowing ESP (or AH if you changed this) traffic to the interface you established as your end point of the tunnel. I will outline that after figure 5.
  2. Encryption algorithms: Ok here is the deal on this. Like before in phase 1, make sure you are setting the algorithm exactly as it is set on the other VPN server. You can use several; when you do so everything you select is available for use. Honestly I like to keep things simple so I recommend only checking the one you are going to use. Use AES-128 (Rijndael) if available.
  3. Hash algorithms: again just as in phase 1 you want to make sure your selected hash matches the one on the other end. And like in step 2, don’t add things you don’t need. MD5 is the suggestion, but SHA1 is always a good alternative.
  4. PFS key group: this works exactly like it does in phase 1. I suggest using 1024 bit, 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 your key. Don’t be over paranoid either; there is no need to set this to 20 minutes or something like that. Honestly, one day is probably good.
  6. Click Save
  7. Click Apply Changes
[edit]

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

In some cases you have a firewall or router with layer 2 routing (protocol ACLs) sitting in front of your pfSense. If this is the case you will need to port forward ESP or AH (depending on which one you chose) to the pfSense. (NOTE: if you are running NAT on that firewall AH will not be an option.)

Previous page Contents Next Page

Retrieved from "http://doc.pfsense.org/index.php/VPN_Capability_IPSec"
Personal tools