S 5.83 Secure connection of an external network with Linux FreeS/WAN

Initiation responsibility: Administrator, Head of IT

Implementation responsibility: Administrator

In many organisations, the local networks installed at the individual locations must be interconnected. In most cases, this is performed using leased lines or public networks not controlled by the organisation. For example, this entails the risk that the transmitted data is intercepted or manipulated or that an attacker pretends to be an authorised communication partner (masquerade). These threats can be counteracted by using a so-called Virtual Private Network (VPN). In this way, the integrity and confidentiality of the data can be protected and the communication partners can be authenticated securely with the help of cryptographic procedures. Linux FreeS/WAN is a free program package for the operating system Linux that can be used to establish a VPN compliant with the IPsec standard.

Planning

In the planning phase, the requirements to be met by the product to be used for protecting the communication connection should at first be determined. For example, this includes the determination of whether it must cooperate with certain existing components or whether other protocols must be transported apart from TCP/IP. Then, the documentation of FreeS/WAN should be worked through and used as a basis for the decision as to whether this program package is suitable for the task at hand. If this is the case, which functionalities of FreeS/WAN are to be used for which purpose and how it is to be integrated into the existing network structure should be defined and documented.

Installation

FreeS/WAN runs on the free operating system Linux and intervenes in the IP protocol stock of the kernel. It is recommendable to operate FreeS/WAN on PCs specifically configured to this end and to not enable any other services on these PCs, except for possibly required routing functions (see also S 4.97 One service per server). In particular, they should not assume any firewall functions, but be independent of the firewall system. A Linux distribution already containing FreeS/WAN should be used in order to install the operating system. This significantly facilitates installation, because otherwise, re-compiling the Linux kernel is normally also required. Regarding this, please refer to the documentation of FreeS/WAN. Furthermore, only the absolutely required program packages should be installed from the Linux distribution.

Configuration

FreeS/WAN implements numerous different functionalities defined in IPSec. Therefore, it is possible to use this program package in many different environments for diverse fields of application by means of corresponding configuration. In the following, an example is used in order to explain how FreeS/WAN can be used in order to protect the communication between two local networks via the internet. For this, the following arrangement of components in the networks is considered:

Components in the networks
Figure: Components in the networks

The two locations West and East of an organisation are both connected to the internet. A multi-stage firewall system is used on both sides that is only represented by a single symbol in the figure for the purposes of simplification, however. gateway.west and gateway.east are IT systems in the operating system Linux that are to be used as gateways for the local networks lan.west and lan.east with the help of FreeS/WAN. The gateways each have two network cards used to connect them to the firewall systems and the local networks. The goal is to enable all IT systems in lan.west and lan.east to communicate securely with each other. The protection of the communication is to be transparent for these IT systems.

It is important to select an appropriate procedure for key management. It is recommended to use automatic key exchange via public key procedures (RSA). Compared to the other procedures supported by FreeS/WAN, this provides the highest level of security. Therefore, the first configuration step consists of generating pairs of RSA keys for the two gateways. For example, this can be achieved by using the ipsec rsasigkey command. The keys should have a minimum length of 768bits. As mentioned in the documentation, the keys generated by means of the aforementioned procedure must only be used for signatures, but not for encryption. This is guaranteed with the FreeS/WAN program package. The output of the ipsec rsasigkey command contains the public and the private RSA key in each case. Regarding the security of the VPN, it is decisive that the private key must not be compromised in any case (see also S 2.46 Appropriate key management).

The private key is stored to the gateway using the /etc/ipsec.secrets file; ownership and permissions must be configured as follows:
-rw------- root root /etc/ipsec.secrets

The public key, on the other hand, is entered into the /etc/ipsec.conf file (see below). This file is also used to perform all other settings for FreeS/WAN. The format is designed in such a way that the same file can be used on both gateways as far as possible. Configuration is performed in several sections each including settings in the form of parameter = value. The parameters requiring a differentiation between the two gateways are each prefixed with the keyword left and/or right. The respective instance of FreeS/WAN uses the IP address to automatically identify which of the two parameters is applicable to it. Therefore, the two versions of the /etc/ipsec.conf file stored to the two gateways normally only differ with regard to the interfaces parameter, for example since Ethernet is used on one side and Token Ring is used on the other side. In the following, recommendations regarding the configuration of the /etc/ipsec.conf file are introduced for the example being considered.

Section config setup

In this section, general settings not specific to any connection are performed.

interfaces = ipsec0=eth0

At first, the network interfaces to be used to establish secured connections must be defined in the interfaces parameter. No encrypted packets are sent via any other interfaces. In the example described above, the connection to the firewall is established by the eth0 interface of the gateway in each case.

forwardcontrol = yes

If the forwardcontrol parameter is set to the value yes, FreeS/WAN automatically enables or disables the forwarding of IP packets when IPsec is enabled and/or disabled. This is recommendable, because packets are prevented from being transmitted in an unencrypted manner if the VPN is not available. When booting the Linux system, it should be ensured that the forwarding of IP packets is disabled before the network interfaces are activated. The way this setting is performed depends on the Linux distribution used.

dumpdir =

The dumpdir parameter should be set to an empty value so that the components of FreeS/WAN do not generate any storage images (core dumps) in the event of a program error. Otherwise, there is the risk of unauthorised persons using these storage images to find secret keys, for example.

plutoload = %search
plutostart = %search

The pluto daemon is part of the FreeS/WAN package and serves for automatic key management. The parameters plutoload and plutostart are used to define which connections are automatically loaded into the database of pluto and/or enabled during start. It is expedient to set these parameters to the special value %search in each case. This way, those connections identified accordingly by the auto parameter are loaded and/or enabled.

Section conn west-east

In this section, settings specifically applicable to a certain connection are performed, west-east for example.

type = tunnel

With the help of the type parameter, the mode of operation for this connection is defined. Since the present case describes the protection of the network traffic between two local networks by means of gateways, the tunnel mode must be used. The transport mode is only admissible for host-to-host communication; passthrough is only admissible for manual key management.

auto = start

If the parameters plutoload and/or plutostart are set to the specific value %search, the auto parameter defines for the present connection whether it is loaded automatically into the database of pluto and/or enabled during start-up. In the example, the connection is to be enabled directly, which is why the auto parameter is set to the value start.

auth = esp

The auth parameter defines which of the two IPSEC functionalities Encapsulating Security Payload (ESP) or Authentication Header (AH) will be used for the purpose of authentication. In the present case, both encryption and authentication may be performed using ESP. This is the default setting.

authby = rsasig

It is recommendable to perform authentication with the help of digital signatures using the RSA algorithm (setting rsasig). When compared to the "shared secrets" method (setting secret), this provides a higher level of security and simplified administration.

pfs = yes

pfs stands for Perfect Forward Secrecy and means that messages exchanged in the past are not compromised even if the private keys of both gateways are disclosed. (The security of future connections, on the other hand, cannot be guaranteed any more.) The default value yes is the recommended setting for this parameter.

keyingtries = 0

The keyingtries parameter defines the maximum number of attempts for establishing or refreshing the corresponding connection. It is recommendable to set the specific value 0, i.e. the number of attempts is not limited. The preset value 3 for the keyingtries parameter is insufficient for the majority of applications.

left = <IP address from gateway.west>
right = <IP address from gateway.ost>

With the help of the parameters left and right, the IP addresses of both gateways involved are set. It is recommendable to enter the IP addresses as numerical value and to not use the specific value %defaultroute. By comparison with the IP addresses assigned to the corresponding network interfaces of the IT system, FreeS/WAN can detect which of the two roles (left or right) is assumed by this IT system.

leftnexthop = <IP address from firewall.west>
rightnexthop = <IP address from firewall.east>

The IP address of the component forwarding the packets using the insecure network must be entered as a value for the parameters leftnexthop and rightnexthop in each case. In the present example, this component is part of the firewall system. Depending on the segmentation and arrangement of the active network components in the local network, the nearest router along the way to the internet firewall must be entered in many cases here.

leftsubnet = <Subnet/mask of lan.west>
rightsubnet = <Subnet/mask of lan.east>

These two parameters can be used to define which two subnets must communicate securely with each other. In the present example, these are the local networks lan.west and/or lan.east. The values must be entered in the form Subnet/mask, for example 10.10.0.0/16.

leftid = @gateway.west
rightid = @gateway.east

The parameters leftid and rightid are used to assign names to the two gateways required for authentication. It is recommendable to define names in the form of DNS names with prefixed "@" symbol. This prevents FreeS/WAN from converting the DNS names into IP addresses before these are used by a query with the DNS server.

leftrsasigkey = <public RSA key of gateway.west>
rightrsasigkey = <public RSA key of gateway.east>

With the help of these two parameters, the public keys of the gateways are defined. The corresponding secret keys, on the other hand, must be entered into the /etc/ipsec.secrets file on the respective gateway.

Routing

FreeS/WAN uses the routing tables of the underlying Linux for forwarding IP packets. With the help of the route command, rules must therefore be generated on both gateways so that packets for the local and/or remote network are forwarded using the corresponding network card.

Remote administration of a gateway

gateway.west and gateway.east cannot communicate using the VPN in the preset configuration. The secure tunnel only transports data between lan.west and lan.east. This is desired for reasons of security, unless one of the two gateways is to be administered by the other side. In this case, the ipsec.conf file must be used to create another connection. This additional connection differs from the connection west-east by the fact that the leftsubnet parameter is missing (if gateway.west is to be administered remotely by lan.east) and/or the rightsubnet parameter is missing (if gateway.east is to be administered remotely by lan.west).

Firewall settings

firewall.west and firewall.east should be configured in such a way that the encrypted use packets and the required management packets can be exchanged between the two gateways. In the present example, the following rules are required in this regard:

If, in deviation from the example, the auth parameter was set to the value ah, IP packets with protocol number 51 must be allowed to pass. Any other communication with the gateway or with the local network must be prevented by the respective firewall system.

Since the firewall system and the gateway are implemented separately, the parameters leftfirewall and rightfirewall, as well as leftupdown and rightupdown should not be used.

When using Network Address Translation (NAT), it must be observed that the address translation must either be performed on a component between the gateway and the local network or on the gateway itself. In general, the addresses cannot be translated within the firewall system. The reason for this is that parts of the IP packets are modified when using NAT so that the integrity check of IPSec normally fails. Therefore, NAT must only be performed after the IPSec gateway. If address translation is to be performed on the same IT system that also operates FreeS/WAN, it must be observed that processing the IP packets on this IT system is rendered very complex as a consequence of this. Information on this can be found in the documentation for FreeS/WAN. Performing NAT on a separate component between the gateway and the local network provides for more clarity and ease-of-administration.

Function test of the VPN

Before live operation, it should be checked whether the VPN works as desired. Instead of the two local networks, only test computers should be connected to the gateways during the trial phase. Otherwise, it cannot be ruled out that data from live operation is transmitted via the internet in an unencrypted manner if the VPN does not work properly right from the beginning.

It should be checked whether the packets are actually encrypted. As described in the documentation, this is performed most easily using the tools ping and tcpdump. With the help of ping, easily discernible IP packets can be created, and tcpdump can be used to read the network traffic generated thereof by FreeS/WAN. It must be noted that the ping command must be executed on the test computer and not on the gateway. Within the framework of the exemplary configuration presented, the VPN only protects the traffic between the local networks (replaced by one or several test computers during the trial phase) and not the traffic from or to the gateways. (For this, see also paragraph Remote administration of a gateway.) The tcpdump command for reading the generated network traffic may be executed on any IT system between the two gateways.

If the VPN does not work as required, for example no communication is possible at all or the network traffic is not encrypted, FreeS/WAN offers comprehensive diagnostics options. For example, information regarding the status of the program package can be found using the contents of the pseudo file /proc/net/ipsec_tncfg and using the ipsec look command. More detailed information about the aforementioned can be found in the documentation for FreeS/WAN.

Review questions:

© Federal Office for Information Security. All rights reserved.