wiki.ipfire.org

The community-maintained documentation platform of IPFire

User Tools

Site Tools


en:configuration:services:ipsec

IPsec

Internet Protocol Security (IPSec) was developed in 1990's and provides a security architecture for the communication over IP networks. IPsec is used to ensure data privacy, authenticity and integrity.

IPSec is used in unsafe environments (like the public internet) to prevent others from intercepting and reading data you send across the network, while simultaneously allowing you to verify that the data has not been intercepted and modified in transit. IPSec is commonly used to safely connect two networks to each other over the internet, such as the scenario where a branch office is connected to a central office. However, IPSec can also be used to connect a device to the network behind a firewall (aka “Road Warrior”). More details can be found here.

IPsec sends log messages to the system log ( /var/log/messages ) and can therefore be found in the WUI ( Logs»System logs, choosing “IPsec” section ).

Security

The whole point of IPsec (or any other VPN solution) is to secure your communications and ensure that any traffic you send has not been modified while in transit. If you are not careful, it is possible to create a VPN tunnel that is not sufficiently secure to properly safeguard your data.

To this end, it is imperative that you spend some time learning about what you need to do to properly set up an IPsec tunnel. Reading the Strongswan Security Recommendations is a good place to start. While this information is geared to IPSec tunnel implementations, it is just as important to proceed carefully when creating other types of VPN tunnels.

Introduction

The examples on this page assume that your IPFire devices are connected directly to the internet. If you have some sort of NAT router between you and the public internet, you should first eliminate that router by removing it or by setting it into “Bridge” mode.

Additionally, we assume that you have either a static IP for your Red interface, or if you do not, we assume that you have an automatically updated dynamic DNS hostname. While you can use a dynamic IP address without a dynamically updated hostname, you will have to modify your settings each and every time that your address changes.

Virtual Private Networks (VPN) using IPSec can be defined as a Host-to-Net VPN (RoadWarrior) or a Net-to-Net VPN. Both types of configuration are described below.

Global configuration

To begin, configure the global settings. For Net-to-Net connections this has to be done on both sides.

  1. Public IP or FQDN for RED interface or <%defaultroute>:
    • If you have a static IP Address, enter that here.
    • If you have a dynamic IP Address, enter the dynamic DNS name here.
    • You may also enter “%defaultroute” here. This may be preferred to using a a dynamic DNS name, as it will eliminate some hostname lookups and may improve recovery when your address changes, but YMMV.
  2. Delay before launching VPN (seconds): If you are using a Dynamic IP Address, you may enter a delay here to allow the Dynamic DNS name to update before starting IPSec. A setting of 60 is a good place to start.
  3. Host-to-Net Virtual Private Network (RoadWarrior): See the Host-to-Net example below.

Roadwarrior connection (Host-to-Net)

With a Roadwarrior connection it´s possible to access the services of the server ( IPFire ) from an outside client.

2._host-to-net.jpg

Example Configuration - Roadwarrior with Windows
Example Configuration - Roadwarrior with Android
Example Configuration - Roadwarrior with Windows Phone 8.1

FIXME Roadwarrior connections with Linux and Mac OS Systems are missing at the moment.

Net-to-Net Connection

A Net-to-Net connection, connects two networks (for example, the green networks behind two IPFire boxes) over the internet.

3._net-to-net.jpg

Example Net2Net with Preshared Key

4._connections_presharedkey.jpg

A connection using a pre-shared key is simpler to create, but it is less secure than a connection using certificates. If you are going to use a PSK, be certain that you use a long and random key (see below for details).

Important: Due to the change from OpenSWAN to StrongSWAN in versions of IPFire 2.7 and later, you must specify a “Local ID” and “Remote ID” when creating a pre-shared Key (PSK) connection.

Important: If you define a pre-shared Key be sure that it does not contain a comma.

Settings on IPFire 1

  1. Choose a name for this connection.
  2. Fill in the External IP Address or hostname of “IPFire 2” in the “Remote host/IP” field.
  3. If you have multiple subnets (Blue and Green, for example) behind this machine, modify the “Local subnet” field to reflect those subnets, separated by a comma. You can use either CIDR (10.1.0.0/16) or Dot-Decimal (255.255.0.0) format. Keep in mind that you may have to properly configure the “Blue Access” and Firewall rules to allow traffic to/from Blue.
  4. Enter the remote network(s) behind IPFire 2 to which this tunnel will connect in the “Remote subnet” field. If you have multiple subnets behind IPFire 2, you can enter multiple subnets separated by a comma.
  5. Choose “Using a pre-shared key:” and set it. You will use the SAME key when configuring IPFire 2.
    • To ensure proper security, it is very important that you choose a key that is both long and random (See the Security Recommendations for more details.
    • The recommended way to create a strong PSK is to run the command dd if=/dev/urandom count=1 bs=32 2>/dev/null | base64 from the command line. Then copy the output of that command and use the output as your PSK.
  6. Click “Save” to save the settings and enable to tunnel.

Settings on IPFire 2

  1. Choose a name for this connection. It does not need to be the same as what you entered on IPFire 1.
  2. If you have multiple subnets (Blue and Green, for example) behind this machine, modify the “Local subnet” field to include those subnets in a comma separated list.
    • Keep in mind that you may have to properly configure the “Blue Access” and Firewall rules to allow traffic to/from Blue.
  3. Fill in the IP address or hostname of IPFire 1 in the “Remote host/IP” field.
  4. Enter the network and subnet mask for the subnet(s) behind IPFire 1 in the “Remote subnet” field.
  5. Choose “Using a pre-shared key:” and enter the same key you used on IPFire 1.
  6. Click “Save” to save your settings and bring up the tunnel.

After a short time the tunnel should be established.

Example Net2Net with certificate

Using certificates is generally more secure than using a PSK, and is preferred for this reason. While it does seem complicated at first, it is actually fairly simple.

Before adding the tunnel:

  1. Generate certificates on both IPFire installations using the controls at the bottom of the IPSec page.
    1. Be certain to fill in valid and useful data when generating the certificates. This will help you tell them apart in the future.
  2. Download the Root and Host certificates from both boxes.
  3. Rename the Root and Host certificates to something unique, like “IPFire1Root.pem” and “IPFire2Host.pem”. Do not use and spaces or special characters in the names.
  4. Using the controls at the bottom of the IPSec page, import each machine's Root certificate to the other.

To add the tunnel:

  1. Follow the instructions above for using a PSK
  2. Do not select “Use a pre-shared key” radio button and do not enter a pre-shared key.
  3. Select the “Upload a certificate” radio button.
  4. Select the Host Certificate of the IPFire on the other end of the tunnel using the “Browse” button on the right.
  5. Click “Save” to save your settings and enable the tunnel.

Advanced Settings and Cipher Selection

Some of the encryption schemes supported by IPSec are widely considered insecure, but are included for backwards compatibility with older devices that are still common. MODP-1024, MODP-1536, SHA1, and MD5 are all examples of insecure ciphers that should generally be avoided unless you absolutely MUST use them.

You can select which encryption methods will be used by a tunnel on the advanced settings page, but that is not enough, as Strongswan (the software implementing IPSec on IPFire) will, by default, use any compatible encryption scheme *if the other side initiates the connection*. The way to avoid this is to enable the “IKE+ESP: Use only proposed settings” checkbox, which will ensure that only those ciphers you select on the advanced settings page will be used.

You may prefer to leave this checkbox disabled until you have successfully established a tunnel. Then, once you know it is working, you can enable it and confirm that doing so does not cause a problem. If selecting the “IKE+ESP: Use only proposed settings” checkbox does prevent you from successfully establishing a tunnel, then the methods you have selected are not supported by the remote device, and you will need to select different settings that are supported by the remote device.

Net to Net:

When setting up a tunnel that will always be connecting the same two devices, it is a good idea to choose a single combination of ciphers on both sides. Selecting multiple options in the various areas serves no purpose.

Road Warrior

When setting up a Road Warrior tunnel, you should limit the available ciphers to those supported by the devices that you know will be connecting to your server. It will likely make sense to select multiple choices in each selection box to ensure that different devices supporting different schemes will all work.

Settings for users of WatchGuard devices

Problem:

  • It is possible that the IPFire complains with an “address family inconsistent”, when a VPN tunnel trying to connect to a Watchguard device with static public IP address! The log entry looks like this: “packet from xxx.xxx.xxx.xxx:500: initial Aggressive Mode message from xxx.xxx.xxx.xxx but no (wildcard) connection has been configured with policy=PSK”

Solution:

  • To solve this problem, go over the webinterface to network → Edit Hosts and create a pseudo DNS-name for the remote site. For example: firewall.example.com . Register this DNS-name then under services → IPSec →“connection as the “Remote host/IP”. After that the tunnel should work! Unless you use 3DES! More on that in the next issue.

Problem:

  • In phase II of the tunnel buildup IPFire and the remote site complains over “NO PROPOSAL CHOSEN”. This problem is only reproducible with DES and 3DES cipher!

Solution:

  • The solution is quiet easy, simply use AES256 in phase II ☺ (naturally on both sides). It is apparently so that StrongSwan uses (the IPSec implementation in IPFire) the version 160 of 3DES, the device from Watch Guard using version 192 of 3DES! Therefore the phase II is not terminated.

Other devices

Advanced Configurations

Translations of this page?:
en/configuration/services/ipsec.txt · Last modified: 2015/12/18 00:44 by trymes