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 ).
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.
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.
To begin, configure the global settings. For Net-to-Net connections this has to be done on both sides.
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.
Example Configuration - Roadwarrior with Windows
Example Configuration - Roadwarrior with MacOS
Example Configuration - Roadwarrior with Android
Example Configuration - Roadwarrior with Windows Phone 8.1
Instructions for Roadwarrior connections with Linux systems are missing at the moment.
A Net-to-Net connection, connects two networks (for example, the green networks behind two IPFire boxes) over the internet.
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:
To add the tunnel:
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.
dd if=/dev/urandom count=1 bs=32 2>/dev/null | base64from the command line. Then copy the output of that command and use the output as your PSK.
After a short time the tunnel should be established.
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.
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.
VPNs can be configured in two modes:
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.
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.