How to configure FreeS/WAN

This page will teach you how to configure a simple network-to-network link or a Road Warrior connection between two Linux FreeS/WAN boxes.

See also these related documents:

The network-to-network setup allows you to connect two office networks into one Virtual Private Network, while the Road Warrior connection secures a laptop's telecommute to work. Our examples also show the basic procedure on the Linux FreeS/WAN side where another IPsec peer is in play.

Shortcut to net-to-net.
Shortcut to Road Warrior.

Requirements

To configure the network-to-network connection you must have:

For the Road Warrior you need:

If both IPs are dynamic, your situation is a bit trickier. Your best bet is a variation on the Road Warrior, as described in this mailing list message.

Net-to-Net connection

Gather information

For each gateway, compile the following information:

Get your leftrsasigkey

On your local Linux FreeS/WAN gateway, print your IPsec public key:

    ipsec showhostkey --left

The output should look like this (with the key shortened for easy reading):

    # RSA 2048 bits   xy.example.com   Fri Apr 26 15:01:41 2002
    leftrsasigkey=0sAQOnwiBPt...

Don't have a key? Use ipsec newhostkey to create one.

...and your rightrsasigkey

Get a console on the remote side:

    ssh2 ab.example.com

In that window, type:

    ipsec showhostkey --right

You'll see something like:

    # RSA 2192 bits   ab.example.com   Thu May 16 15:26:20 2002
    rightrsasigkey=0sAQOqH55O...

Edit /etc/ipsec.conf

Back on the local gate, copy our template to /etc/ipsec.conf. (on Mandrake, /etc/freeswan/ipsec.conf). Substitute the information you've gathered for our example data.

conn net-to-net
    left=192.0.2.2                 # Local vitals
    leftsubnet=192.0.2.128/29      # 
    leftid=@xy.example.com         #   
    leftrsasigkey=0s1LgR7/oUM...   #
    leftnexthop=%defaultroute      # correct in many situations 
    right=192.0.2.9                # Remote vitals
    rightsubnet=10.0.0.0/24        #
    rightid=@ab.example.com        # 
    rightrsasigkey=0sAQOqH55O...   #
    rightnexthop=%defaultroute     # correct in many situations
    auto=add                       # authorizes but doesn't start this 
                                   # connection at startup

"Left" and "right" should represent the machines that have FreeS/WAN installed on them, and "leftsubnet" and "rightsubnet" machines that are being protected. /32 is assumed for left/right and left/rightsubnet parameters.

Copy conn net-to-net to the remote-side /etc/ipsec.conf. If you've made no other modifications to either ipsec.conf, simply:

    scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf

Start your connection

Locally, type:

    ipsec auto --up net-to-net

You should see:

    104 "net-net" #223: STATE_MAIN_I1: initiate
    106 "net-net" #223: STATE_MAIN_I2: sent MI2, expecting MR2
    108 "net-net" #223: STATE_MAIN_I3: sent MI3, expecting MR3
    004 "net-net" #223: STATE_MAIN_I4: ISAKMP SA established
    112 "net-net" #224: STATE_QUICK_I1: initiate
    004 "net-net" #224: STATE_QUICK_I2: sent QI2, IPsec SA established

The important thing is IPsec SA established. If you're unsuccessful, see our troubleshooting tips.

Do not MASQ or NAT packets to be tunneled

If you are using IP masquerade or Network Address Translation (NAT) on either gateway, you must now exempt the packets you wish to tunnel from this treatment. For example, if you have a rule like:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE

change it to something like:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE

This may be necessary on both gateways.

Test your connection

Sit at one of your local subnet nodes (not the gateway), and ping a subnet node on the other (again, not the gateway).

    ping fileserver.toledo.example.com

While still pinging, go to the local gateway and snoop your outgoing interface, for example:

    tcpdump -i ppp0

You want to see ESP (Encapsulating Security Payload) packets moving back and forth between the two gateways at the same frequency as your pings:

    19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
    19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)

If you see this, congratulations are in order! You have a tunnel which will protect any IP data from one subnet to the other, as it passes between the two gates. If not, go and troubleshoot.

Note: your new tunnel protects only net-net traffic, not gateway-gateway, or gateway-subnet. If you need this (for example, if machines on one net need to securely contact a fileserver on the IPsec gateway), you'll need to create extra connections.

Finishing touches

Now that your connection works, name it something sensible, like:

conn winstonnet-toledonet

To have the tunnel come up on-boot, replace

    auto=add

with:

    auto=start

Copy these changes to the other side, for example:

    scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf

Enjoy!

Road Warrior Configuration

Gather information

You'll need to know:

Get your leftrsasigkey...

On your laptop, print your IPsec public key:

    ipsec showhostkey --left

The output should look like this (with the key shortened for easy reading):

    # RSA 2192 bits   road.example.com   Sun Jun  9 02:45:02 2002
    leftrsasigkey=0sAQPIPN9uI...

Don't have a key? See these instructions.

...and your rightrsasigkey

Get a console on the gateway:

    ssh2 xy.example.com

View the gateway's public key with:

    ipsec showhostkey --right

This will yield something like

    # RSA 2048 bits   xy.example.com   Fri Apr 26 15:01:41 2002
    rightrsasigkey=0sAQOnwiBPt...

Customize /etc/ipsec.conf

On your laptop, copy this template to /etc/ipsec.conf. (on Mandrake, /etc/freeswan/ipsec.conf). Substitute the information you've gathered for our example data.

conn road
    left=%defaultroute             # Picks up our dynamic IP 
    leftnexthop=%defaultroute      # 
    leftid=@road.example.com       # Local information
    leftrsasigkey=0sAQPIPN9uI...   #
    right=192.0.2.10               # Remote information
    rightsubnet=10.0.0.0/24        #
    rightid=@xy.example.com        # 
    rightrsasigkey=0sAQOnwiBPt...  #
    auto=add                       # authorizes but doesn't start this
                                   # connection at startup

The template for the gateway is different. Notice how it reverses left and right, in keeping with our convention that Left is Local, Right Remote. Be sure to switch your rsasigkeys in keeping with this.

    ssh2 xy.example.com
    vi /etc/ipsec.conf

and add:

conn road
    left=192.0.2.2                 # Gateway's information
    leftid=@xy.example.com         #
    leftsubnet=192.0.2.128/29      #
    leftrsasigkey=0sAQOnwiBPt...   #
    rightnexthop=%defaultroute     # correct in many situations
    right=%any                     # Wildcard: we don't know the laptop's IP
    rightid=@road.example.com      #
    rightrsasigkey=0sAQPIPN9uI...  #
    auto=add                       # authorizes but doesn't start this
                                   # connection at startup

Start your connection

You must start the connection from the Road Warrior side. On your laptop, type:

    ipsec auto --start net-to-net

You should see:

104 "net-net" #223: STATE_MAIN_I1: initiate
106 "road" #301: STATE_MAIN_I2: sent MI2, expecting MR2
108 "road" #301: STATE_MAIN_I3: sent MI3, expecting MR3
004 "road" #301: STATE_MAIN_I4: ISAKMP SA established
112 "road" #302: STATE_QUICK_I1: initiate
004 "road" #302: STATE_QUICK_I2: sent QI2, IPsec SA established

Look for IPsec SA established. If you're unsuccessful, see our troubleshooting tips.

Do not MASQ or NAT packets to be tunneled

If you are using IP masquerade or Network Address Translation (NAT) on either gateway, you must now exempt the packets you wish to tunnel from this treatment. For example, if you have a rule like:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE

change it to something like:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE

Test your connection

From your laptop, ping a subnet node behind the remote gateway. Do not choose the gateway itself for this test.

    ping ns.winston.example.com

Snoop the packets exiting the laptop, with a command like:

    tcpdump -i wlan0

You have success if you see (Encapsulating Security Payload) packets travelling in both directions:

    19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
    19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)

If you do, great! Traffic between your Road Warrior and the net behind your gateway is protected. If not, see our troubleshooting hints.

Your new tunnel protects only traffic addressed to the net, not to the IPsec gateway itself. If you need the latter, you'll want to make an extra tunnel..

Finishing touches

On both ends, name your connection wisely, like:

conn mike-to-office

On the laptop only, replace

    auto=add

with:

    auto=start

so that you'll be connected on-boot.

Happy telecommuting!

Multiple Road Warriors

If you're using RSA keys, as we did in this example, you can add as many Road Warriors as you like. The left/rightid parameter lets Linux FreeS/WAN distinguish between multiple Road Warrior peers, each with its own public key.

The situation is different for shared secrets (PSK). During a PSK negotiation, ID information is not available at the time Pluto is trying to determine which secret to use, so, effectively, you can only define one Roadwarrior connection. All your PSK road warriors must therefore share one secret.

What next?

Using the principles illustrated here, you can try variations such as:

Or, look at some of our more complex configuration examples..