This page will teach you how to configure a simple network-to-network link or a Road Warrior connection between two Linux machines running Openswan.
See also these related documents:
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 RoadWarrior.
For each gateway, compile the following information:
On your local Linux Openswan 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.
Get a console on the remote side:
# ssh 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...
Back on the local gateway, copy our template to /etc/ipsec.conf. (on Mandrake, /etc/openswan/ipsec.conf). Substitute the information you've gathered for our example data.
conn net-to-net
left=192.0.2.2 # Local vitals
leftsubnet=172.16.0.0/24 #
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 Openswan 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:
# scp ipsec.conf root@ab.example.com:/etc/ipsec.conf
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.
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 ! 172.16.0.0/24 -j MASQUERADE
This may be necessary on both gateways.
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 see our Troubleshooting page.
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.
Now that your connection works, name it something sensible, like:
conn newyork-net-to-washington-net
To have the tunnel come up on-boot, replace
auto=add
with:
auto=start
Copy these changes to the other side, for example:
# scp ipsec.conf root@ab.example.com:/etc/ipsec.conf
Enjoy!
You'll need to know:
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.
Get a console on the gateway:
# ssh 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...
On your laptop, copy this template to /etc/ipsec.conf. (on Mandrake, /etc/openswan/ipsec.conf). Substitute the information you've gathered for our example data.
conn road
left=%defaultroute # Picks up our dynamic IP
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.
ab.example.com$ ssh xy.example.com xy.example.com$ vi /etc/ipsec.conf
and add:
conn road
left=192.0.2.2 # Gateway's information
leftid=@xy.example.com #
leftsubnet=176.16.0.0/24 #
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
You must start the connection from the Road Warrior side. On your laptop, type:
ipsec auto --up road
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.
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 (note the ! - this means *exclude* 176.16.0.0/24 from the NAT/Masquerading):
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d ! 176.16.0.0/24 -j MASQUERADE
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 a successful tunnel up if you see ESP (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 see the ESP packets, then traffic between your RoadWarrior 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.
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!
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 Openswan 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.
Using the principles illustrated here, you can try variations such as:
Or, look at some of our more complex configuration examples..
