Installing and Configuring a Linux VPN Server (Part 2)

You might notice that the next section is a connection description for the purpose of opportunistic encryption, an experimental feature. Since you likely won’t be using this, comment out this section or remove it altogether.

The last critical configuration task will be creating our connection description. Consider directly editing the sample as opposed to re-typing everything. You’ll need the information from the diagram created earlier to fill in all of the variables. By examining the sample diagram, setting the majority of the connection variables below should be obvious:

conn london-accra

For cases where you have multiple subnets behind the gateway, configuration will simply involve changing the subnet mask value in the left or right subnet= field. For example, If you had both the and networks in a location, you could summarize them by changing the mask value to /23. If you are testing in a lab environment without a router, the nexthop sections of the connection can be removed, but in production they will be necessary. The final option in this section is a variable called auto=add. If uncommented in its current state, the connection will be added to memory when the system boots but will not be started. To have the connection start automatically, change this option to start. For the purpose of testing, uncomment it and leave it set to add. After being sure it works, you can change it to start.

After your configuration is complete, remember that this ipsec.conf file will need to be transferred to the /etc directory on the Accra server, overwriting the default file that still exists there. After this is complete, reboot both servers. After both are again online, and assuming you have left the auto= option in ipsec.conf set to add, you can initiate the connection from one of the systems. For my london-accra connection, the command is:
ipsec auto —up london-accra

After doing so, you should see a brief negotiation message mentioning that a security association has been established. If not, you’ve likely made an error in the ipsec.conf file. An important note here; while the connection need only be initiated from one of the systems, it should always be shut down on both systems. If not, it will continue to wait for re-establishment, wasting system resources. To shut down a connection from either server, use the command:

ipsec auto —down london-accra

To view the currently connected tunnels use:

ipsec look

After the tunnels have been created, you’ll want to be sure that the traffic moving between them is encrypted. One common mistake is simply pinging from one FreeS/WAN gateway to the other. This doesn’t prove anything, since the only traffic that will be encrypted is that which moves from one subnet to the other. To test properly, you should attempt to make a connection from one subnet to the other and capture the traffic that moves between the two. For example, start a file transfer from a client in Accra to a server in London. To view the actual data stream, set up an intermediate system with a packet capture utility such as Ethereal. If data is properly ESP-encrypted, you should see a number of protected packets whose contents cannot be viewed, as shown here. The source and destination addresses should be the respective gateways.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.