This wiki is a community-maintained resource about everything there is to know about IPFire.
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. Dynamic DNS hostnames are configured in the WebGUI underServices / 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.
To begin, enable IPsec by checked the "Enabled" checkbox and hit "Save".
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:
Use meaningful and valid data when generating the certificates. This will help you distinguish them in the future.
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
FIXME 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.
Tunnel information has to be added on both IPFires.
In the following screen "Connection" fill in the following information:
In the following screen "Connection" fill in the following information:
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.
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. 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.
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 .
It needs to be noted, that both IPFire installations useunbound 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.
# This is the file to include zone green2.xx as an insecure zone # server: domain-insecure: green2.xx
# This is the file to include zone green1.xx as an insecure zone # server: domain-insecure: green1.xx
For further details refer to man pages of unbound.conf: https://nlnetlabs.nl/documentation/unbound/unbound.conf/
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.
* 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"
To solve this problem, go over the webinterface tonetwork -> Edit Hosts and create a pseudo DNS-name for the remote site. For example: firewall.example.com . Register this DNS-name then underservices -> IPSec ->"connection"* as the "Remote host/IP". After that the tunnel should work! Unless you use 3DES! More on that in the next issue.
* 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!
* 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.