From Wiki
Revision as of 11:54, 6 July 2009 by Gerard (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Openswan is a complete IPsec implementation for Linux 2.0, 2.2, 2.4 and 2.6 kernels.

Openswan began as a fork of the now-defunct FreeS/WAN project, and continues to be released freely under the GNU General Public License. Unlike the FreeS/WAN project, it is not developed exclusively for the Linux operating system.

Installing Openswan

In Debian is as easy as:

aptitude install openswan

Configure OpenSwan between 2 openswan

On the /etc/ipsec.conf

conn linux-linux
       type=tunnel                  # host to host tunnel
       authby=secret                # authorized by shared secrets
       left=          # one side of the tunnel
       leftnexthop=   # next hop fro the left side
       leftsubnet=     # subnet on the left
       right=         # the other side of the tunnel
       rightnexthop=  # next hop for the right side
       rightsubnet=    # network on the right
       ike=3des-sha1-96             # first statge authentication
       esp=3des-sha1-96             # second stage
       ikelifetime=1440m            #  Life time for the fist stage authentication
       keylife=86400s               #  Life time for the second stage authentication
       auto=start                   #  Start at boot time

We need to generate a secure password for autehtication by:

ipsec ranbits 128

And then add it in the /etc/ipsec.secrets PSK "0x205e3332_93ed0e56_03b58c08_75ef2c4c"

We just need to copy these two files on both sides of the tunnel (the same files) and

/etc/init.d/ipsec restart

To start and stop only one connection we can:

ipsec auto --add name

Bring it up:

ipsec auto --up name

Bring it down:

ipsec auto --down name

Troubleshoot ipsec

ipsec auto status
000 "linux-linux":; erouted; eroute owner: #4
000 "linux-linux":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
000 "linux-linux":   ike_life: 86400s; ipsec_life: 86400s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "linux-linux":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 24,24; interface: eth0; encap: esp;
000 "linux-linux":   newest ISAKMP SA: #5; newest IPsec SA: #4; 
000 "linux-linux":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA1(2)-MODP1536(5), 3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict
000 "linux-linux":   IKE algorithms found: 3DES_CBC(5)_192-SHA1(2)_096-MODP1536(5), 3DES_CBC(5)_192-SHA1(2)_096-MODP1024(2)
000 "linux-linux":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1536
000 "linux-linux":   ESP algorithms wanted: 3DES(3)_000-SHA1(2); flags=strict
000 "linux-linux":   ESP algorithms loaded: 3DES(3)_000-SHA1(2); flags=strict
000 "linux-linux":   ESP algorithm newest: 3DES_0-HMAC_SHA1; pfsgroup=<Phase1>
000 #2: "linux-linux":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 84730s; newest IPSEC; eroute owner
000 #2: "linux-linux" esp.600d75db@ esp.eed7c1bf@ tun.0@ tun.0@
000 #1: "linux-linux":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 84946s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)

The main important thing here is to see if:

ipsec stablished (phase 2):

000 #2: "linux-linux":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 84730s; newest IPSEC; eroute owner

ike stablished (phase 1):

000 #1: "linux-linux":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 84946s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)

We can tcpdump the link while we are doing pings, then we should see:

19:07:49.967730 IP > ESP(spi=0xeed7c1bf,seq=0x11), length 116
19:07:50.975471 IP > ESP(spi=0x600d75db,seq=0x12), length 116

NAT before entering the tunnel

We can even translate the directions for a specific tunnel and pretend that we re leaving the tunnel with a network that is not the one that we are really using.

Imagine that you have this network diagram:

          MADRID                      INTERNET                BARCELONA
---------------------------------  --------------   --------------------------------        ===   .............. ===

But the range is already used in Madrid, so we can not set up the VPN with this range. So, what we can do is masquerade the VPN by, showing to madrid that we will use by Natting the traffic before entering the tunnel:

So we are going to configure this VPN:

         MADRID                    INTERNET               BARCELONA
--------------------------------  ----------  ---------------------------------------------------------------------------- ===  .......... ===  <- that is 1-to-1 NAT to ->; 

iptables will NAT the traffic. But first we need to set up an IP address that we are going to use as NAT.

ip a add dev lo

everything that comes from the VPN, with destination we are going to change the destination to before routing the packet:

iptables -t nat -A PREROUTING -d -i eth0 -j DNAT --to-destination 

and everything that leaves to the VPN with soruce we are going to change the source address for after routing.

iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source

Furthermore we can NAT the packet in our network changing the source address to instead of using our VPN peer local network:

iptables -t nat -A POSTROUTING -o eth1 -s -j MASQUERADE

Then we don't need any static route in the machine that we want to VPN to. This will work only if the connections are always started in MADRID. If we need some connections started in Barcelona we need also to set up the static routes to route traffic to the VPN gateway.


We should not take the notion of virtual wire too literally. IPsec (as its name implies) is an IP security protocol. It carries IP and nothing else. IP is a layer-3 creature. In contrast, a real ethernet wire has some very specific layer-2 functionality (such as broadcast, multicast, and unicast) plus the ability to carry more than 100 different layer-3 protocols, of which IP is just one.

Suppose you want your virtual wire to carry something other than plain old IP; perhaps NetBEUI, Banyan VINES, Novell IPX, or whatever. You can't expect IPsec to do the job by itself. The obvious solution is to establish IPsec connections (presumably host-to-host connections using transport mode). Then run something like GRE (Generic Router Encapsulation) or L2TP (Layer 2 Tunneling Protocol) which handles layer-2 traffic, encapsulates it in IP, and sends the IP over the IPsec connections. Maybe someday somebody will write some sort of L2sec protocol to provide secure layer-2 connectivity all in one package, but don't count on it.