08/02/2010 VPN Capability IPsec - PFSenseDocs

Search

VPN Capability IPsec Personal tools

Log in
From PFSenseDocs
This article is part of the HOWTO series.

Previous page Contents Next Page

Contents

1 Summary
2 What is IPsec
2.1 Site to Site VPN Explained
2.2 Remote Access IPsec VPN
3 Prerequisites
4 Configuring the VPN Tunnel
5 Add Firewall Rules
6 What if your pfSense isn't the main Internet Firewall?

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.

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
doc.pfsense.org/…/VPN_Capability_IPsec 1/7
08/02/2010 VPN Capability IPsec - PFSenseDocs
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
(http://www.shrew.net/) . 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
doc.pfsense.org/…/VPN_Capability_IPsec 2/7
08/02/2010 VPN Capability IPsec - PFSenseDocs
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,

doc.pfsense.org/…/VPN_Capability_IPsec 3/7
08/02/2010 VPN Capability IPsec - PFSenseDocs
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

doc.pfsense.org/…/VPN_Capability_IPsec 4/7
08/02/2010 VPN Capability IPsec - PFSenseDocs
"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

doc.pfsense.org/…/VPN_Capability_IPsec 5/7
08/02/2010 VPN Capability IPsec - PFSenseDocs
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.

Previous page Contents Next Page

Retrieved from "http://doc.pfsense.org/index.php/VPN_Capability_IPsec"

doc.pfsense.org/…/VPN_Capability_IPsec 6/7
08/02/2010 VPN Capability IPsec - PFSenseDocs
Categories: Documentation | VPN | IPsec | Howto

Privacy policy About PFSenseDocs Disclaimers

This page was last modified on 4 February 2010, at 18:45. This page has been accessed 47,322 times.

doc.pfsense.org/…/VPN_Capability_IPsec 7/7