Common errors at his point mainly involve forgetting to enable the required IP forwarding on the servers. If you haven’t already done this, issue the following command from the prompt for testing purposes:
Echo “1” > /proc/sys/net/ipv4/ip_forward
To enable IP forwarding automatically at startup on a Red Hat system add the following command to /etc/sysconfig/network:
If your configuration uses real IP addresses and routing on both networks, you should already be able to ping systems on the remote LAN without issue. Testing to ensure that the network is communicating correctly prior to configuring FreeS/WAN is critical – isolating the problem source will be difficult if you don’t have this sorted out to begin with.
The two main configuration files that you’ll be dealing with are ipsec.conf and ipsec.secrets, both found in your /etc directory. The ipsec.conf file contains the service start-up parameters, as well as the connection definitions for the tunnels. The ipsec.secrets file contains the private and public RSA key pair that was generated automatically during installation and will be described shortly.
Getting back to that diagram mentioned in the first article, you should designate one side ‘Left’ and the other side ‘Right’. It doesn’t actually matter which is which, as long as the configuration is consistent. Each side should also have a real name based on something like location. In our example, we’re going to build a tunnel from London to Accra, so we’ll call the connection londonaccra, with London being designated the Left side and Accra the Right side, exactly as they are written. Adding this to your diagram will help you immensely during the configuration process.
The first file we’ll work with is ipsec.secrets. On each FreeS/WAN server, this file will contain the server’s public and private key. This key pair is used for authentication purposes, with the only other option being a relatively weak shared secret. While you don’t need to worry about the public part of the key, you definitely should be worried about the protection of its private counterpart. The public part of the key will need to be extracted and ultimately be put into the ipsec.conf file. To do this, I suggest extracting the public key to a separate file on each server, and then setting restrictive permissions on ipsec.secrets.