wiki.ipfire.org

The community-maintained documentation platform of IPFire

User Tools

Site Tools


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. Dynamic DNS hostnames are configured in the WebGUI under Services / Dynamic DNS, see Dynamic DNS. Make sure, that the static IP address / dynamic DNS name is reachable from the other IPFire, e.g. ping from IPFire1 the remote IP address / dynamic DNS name of IPFire2 and ping from IPFire2 the remote IP address / dynamic DNS name of IPFire1.

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.

Generation of Root and Host certificate

Root and Host certificates are required for any IPsec connection, both Host-to-Net, as well as Net-to-Net. For the latter, this needs to be performed on both IPFire1 as well as IPFire2.

Press button “Generate Root/Host certificates” and fill in the following values:

  1. Organisation name: “ipfire1” (or something other useful; no duplicates allowed, no special characters allowed, no white space allowed!)
  2. IPFire's Hostname: the static IP address or dynamic DNS name, see above
  3. Your email: <optional entry>
  4. Your department: <optional entry>
  5. Town: <optional entry>
  6. Province: <optional entry; no special characters allowed>
  7. Country: <choose your country>
  8. Subject Alternative Name: “IP:24.24.24.1>” or “DNS:ipfire1.example1.org” Replace IP address and DynDNS name examples by your values. No spaces allowed in the entry!
  9. Press button “Generate Root/Host certificates”. This generates the certificates (it may take some time) and brings you back to the main page of the Services / IPsec.

Use meaningful and valid data when generating the certificates. This will help you distinguish them in the future.

Roadwarrior connection (Host-to-Net)

So-called “Roadwarrior” connections are those connections that are generally made from a client PC back to the firewall to establish a connection to the Green/Blue networks, or to access the internet through an encrypted tunnel. This is frequently done with OpenVPN, but using IPSec has the major advantage of not requiring the user to install a VPN client on their computer.

2._host-to-net.jpg

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

FIXME Instructions for Roadwarrior connections with Linux 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

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. Download the Root certificate from the first IPFire1. To do that, click button “Download Root certificate” (diskette symbol). You will be asked, where to store the file, e.g. on a USB stick. The default name is cacert.pem. To avoid confusion, change the name e.g. to cacert-ipfire1.pem.
  2. Download the Host certificate from the first IPFire1. To do that, click button “Download Host certificate” (diskette symbol). You will be asked, where to store the file, e.g. on a USB stick. The default name is hostcert.pem. To avoid confusion, change the name e.g. to hostcert-ipfire1.pem.
  3. Download both Root and Host certificate from the second IPFire2 as described for IPFire1. Rename them to to e.g. cacert-ipfire2.pem and hostcert-ipfire2.pem.
  4. Using the controls at the bottom of the IPSec page (“Certificate Authorities and -Keys”), import “IPFire1Root.pem” on IPFire2.
  5. Using the controls at the bottom of the IPSec page (“Certificate Authorities and -Keys”), import “IPFire2Root.pem” on IPFire1.

To add the tunnel:

Tunnel information has to be added on both IPFires.

On IPFire 1:

  1. On WebGUI go to Services / IPSec.
  2. In section Connection Status and -Control press button Add.
  3. In the following screen “Connection Type” choose the radio button Net-to-Net Virtual Private Network and then Add.
  4. In the following screen “Connection” fill in the following information:
    • Connection name: “IPFire1ToIPFire2” (or something similar; use a meaningful name!)
    • Activate “Enabled”
    • Local subnet: should be prefilled with something like “192.168.101.0/255.255.255.0” (must fit to your Green network of your local IPFire1!)
    • Remote Host/IP: “ipfire2.example2.org” (the static IP address / DynDNS name of the Red NIC of your IPFire2)
    • Remote subnet: “192.168.102.0/255.255.255.0” (must fit to your Green network of your remote IPFire2!)
    • Local ID: ”@ipfire1.example1.org“
    • Remote ID: ”@ipfire2.example2.org“
    • Remark: <Any meaningful information which describes your connection>
  5. In the “Authentication” section press radio button Upload a certificate
  6. Now pick appropriate host file. Choose path to USB stick with file “hostcert-ipfire2.pem”
  7. Last press button Save.

Do the same on your IPFire 2:

  1. On WebGUI go to Services / IPSec.
  2. In section Connection Status and -Control press button Add.
  3. In the following screen “Connection Type” choose the radio button Net-to-Net Virtual Private Network and then Add.
  4. In the following screen “Connection” fill in the following information:
    • Connection name: “IPFire2ToIPFire1” (or something similar; use a meaningful name!)
    • Activate “Enabled”
    • Local subnet: should be prefilled with something like “192.168.102.0/255.255.255.0” (must fit to your Green network of your local IPFire2!)
    • Remote Host/IP: “ipfire1.example1.org” (the static IP address / DynDNS name of the Red NIC of your IPFire1)
    • Remote subnet: “192.168.101.0/255.255.255.0” (must fit to your Green network of your remote IPFire1!)
    • Local ID: ”@ipfire2.example2.org“
    • Remote ID: ”@ipfire1.example1.org“
    • Remark: <Any meaningful information which describes your connection>
  5. In the “Authentication” section press radio button Upload a certificate
  6. Now pick appropriate host file. Choose path to USB stick with file “hostcert-ipfire1.pem”
  7. Last press button Save.

Check the tunnel

Now the tunnel should be established. Checkout the connection, e.g. by opening a console on IPFire1, and then ping the Green IP address of IPFire2. Do the same on IPFire2 console, and ping the Green IP address of IPFire1. You should receive Ping responses.

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. Checkout the connection, e.g. by opening a console on IPFire1, and then ping the Green IP address of IPFire2. Do the same on IPFire2 console, and ping the Green IP address of IPFire1.

DNS resolution across VPN tunnels

Established tunnels enable IP traffic between the subnets, but DNS resolution across those subnets needs to be dealt with separately. This is achieved by forwarding DNS requests to the respective DNS server which is working in the remote subnet.

In this example it is assumed that both IPFire 1 as well as IPFire 2 are resolving the DNS names for their local subnets. Consequently DNS name requests from the Green IPFire 1 subnet must be forwarded to IPFire 2, and DNS name requests from the Green IPFire 2 subnet must be forwarded to IPFire 1. This is done by setting up appropriate DNS forwarders, see DNS forwarding .

On IPFire 1:

  1. On WebGUI go to Network / DNS Forwarding.
    • Zone: “green2.xx” (the DNS domain / zone of IPFire 2)
    • Enabled: <activate it>
    • Nameserver: 192.168.102.1 (the IP address of IPFire 2)
    • Remark: <Whatever you like>
  2. Press Add

On IPFire 2:

  1. On WebGUI go to Network / DNS Forwarding.
    • Zone: “green1.xx” (the DNS domain / zone of IPFire 1)
    • Enabled: <activate it>
    • Nameserver: 192.168.101.1 (the IP address of IPFire 1)
    • Remark: <Whatever you like>
  2. Press Add

It needs to be noted, that both IPFire installations use unbound to resolve DNS names. IPFire is configured such, that the remote DNS server MUST provide validated DNS answers. Unfortunately IPFire / Unbound does not provide validated answers when requested. This is not too much of a problem, since both IPFire installations can be trusted. However both IPFires must be configured such, that they accept DNS resolution without validated answer. This can only be configured “under the hood”, i.e. root console, i.e. NOT on the WebGUI.

To achieve that, additional Unbound configuration files need to be added.

On IPFire 1:

  • Open root console.
  • Create file /etc/unbound/local.d/insecure.conf with the following content:
    # This is the file to include zone green2.xx as an insecure zone
    #
    server:
          domain-insecure: green2.xx
  • Save the file.
  • Restart Unbound by the following command on the root console: /etc/init.d/unbound restart

On IPFire 2:

  • Open root console.
  • Create file /etc/unbound/local.d/insecure.conf with the following content:
    # This is the file to include zone green1.xx as an insecure zone
    #
    server:
          domain-insecure: green1.xx
  • Save the file.
  • Restart Unbound by the following command on the root console: /etc/init.d/unbound restart

For further details refer to man pages of unbound.conf: https://nlnetlabs.nl/documentation/unbound/unbound.conf/

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.

Start Actions

VPNs can be configured in two modes:

Always On (Default)

This mode will try to keep the VPN up at all times. If that is not the case, connections through the VPN will be rejected.

On-Demand

In this mode, the VPN connection will be established when needed. If it is not needed any more, it will be shut down after 15 minutes of inactivity. This helps to save resources on not very frequently used VPNs.

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

configuration/services/ipsec.txt · Last modified: 2018/09/07 17:12 by KaPe