OpenSwan

From Wiki
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.

Contents

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=172.16.121.135          # one side of the tunnel
       leftnexthop=172.16.121.130   # next hop fro the left side
       leftsubnet=30.30.30.0/24     # subnet on the left
       right=172.16.121.130         # the other side of the tunnel
       rightnexthop=172.16.121.135  # next hop for the right side
       rightsubnet=20.20.20.0/24    # 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
0x205e3332_93ed0e56_03b58c08_75ef2c4c


And then add it in the /etc/ipsec.secrets

172.16.121.135 172.16.121.130: 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": 30.30.30.0/24===172.16.121.135...172.16.121.130===20.20.20.0/24; 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@172.16.121.136 esp.eed7c1bf@172.16.121.135 tun.0@172.16.121.136 tun.0@172.16.121.135
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 172.16.121.136 > 172.16.121.135: ESP(spi=0xeed7c1bf,seq=0x11), length 116
19:07:50.975471 IP 172.16.121.135 > 172.16.121.136: 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
---------------------------------  --------------   --------------------------------                
10.10.10.0/24 === 172.16.121.136   ..............   172.16.121.137 === 20.20.20.0/24


But the 20.20.20.0/24 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 30.30.30.0/24 by Natting the traffic before entering the tunnel:

So we are going to configure this VPN:

         MADRID                    INTERNET               BARCELONA
--------------------------------  ----------  ----------------------------------------------------------------------------
10.10.10.0/24 === 172.16.121.136  ..........  172.16.121.137 === 30.30.30.30/24  <- that is 1-to-1 NAT to ->  20.20.20.20/24; 


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 30.30.30.30/24 dev lo

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

iptables -t nat -A PREROUTING -d 30.30.30.30/32 -i eth0 -j DNAT --to-destination 20.20.20.20 

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

iptables -t nat -A POSTROUTING -s 20.20.20.20/32 -o eth0 -j SNAT --to-source 30.30.30.30

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

iptables -t nat -A POSTROUTING -o eth1 -s 10.10.10.0/24 -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.



GRE over IPSEC

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.

Personal tools
Namespaces
Variants
Actions
Navigation
Content
Toolbox