Openswan VPN: private-to-private-network

Connecting two private networks with Openswan and Linux is easy. I used Ubuntu 10.04 LTS server in my setup. I would guess, since this setup is so simple, that there won’t be problems getting things working on other distributions with same configuration.

Prerequisites

  • public IP-address for each VPN server without NAT in front
    • you should be able to configure Openswan even if the server is behind NAT, but I won’t cover that in here
  • FQDN is also preferred for each server, but not needed
  • private networks can not be from the same subnet, examples:
    • ok: 10.0.0.0/8 <-> 192.168.0.0/24
    • ok: 192.168.1.0/24 <-> 192.168.0.0/24
    • ok: 10.0.1.0/24 <-> 10.0.0.0/24
    • not ok: 192.168.0.0/24 <-> 192.168.0.0/24
    • not ok: 10.0.3.0/8 <-> 10.0.1.0/24
  • install Openswan on every server (apt-get install openswan)

Example setup

We have two private networks, let’s say 10.0.1.0/24 is our main office network and 10.0.2.0/24 is our side office network. Main office server has public IP-address 22.33.44.55 and side office server has public IP-address 66.77.88.99. Main office server has private IP-address 10.0.1.1 and side office has private IP-address 10.0.2.1. Both servers work as NATed routers for their private networks, which contain unspecified amount of machines (servers, desktops, etc). Main office is considered as “left” and side office as“right” in our configuration. vpn-quick-drawing1

Configuration

RSA-key

Generate RSA-key on each server. You can use couple of ways for this, I went the ‘easy’ way and used ssh-keygen:

root@host:~$ ssh-keygen -f /root/.ssh/vpn
Generating public/private rsa key pair.
...

Edit /etc/ipsec.secrets to point to that key:

# set this to point into your RSA-key
: RSA /root/.ssh/vpn

Next you print out RSA-keys on each end (these are used later in ipsec.conf):

root@main-office:~$ ipsec showhostkey --left
    # rsakey YYY
    leftrsasigkey=.............................

---

root@side-office:~$ ipsec showhostkey --right
    # rsakey XXX
    rightrsasigkey=.............................

/etc/ipsec.conf

Configuration is quite simple. If you have only two servers (like in the example), the configuration file can be exactly the same for both ends:

version 2.0

# basic configuration
config setup
    interfaces=%defaultroute
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    protostack=auto

#####
# main office (left) <-> side office (right) -vpn
conn main-office-side-office
    # public ip
    left=22.33.44.55
    leftid=@main-fqdn.office.com
    # optionally, if fqdn is not set, put public ip here
#    leftid=22.33.44.55
    # private network address on this machine
    leftsourceip=10.0.1.1
    # private network
    leftsubnet=10.0.1.0/24
    # usually public ip address of right
    leftnexthop=66.77.88.99
    # left rsa-key (previously shown how to obtain)
    leftrsasigkey=...

    # public ip
    right=66.77.88.99
    # same here, if no fqdn is set, use public ip
    rightid=@side-fqdn.office.com
    rightsourceip=10.0.2.1
    rightsubnet=10.0.2.0/24
    # usually public ip address of left
    rightnexthop=22.33.44.55
    # right rsa-key
    rightrsasigkey=...

    auto=start

Now start Openswan on both ends. If all goes well, your VPN starts working.

root@host:~$ service ipsec restart
...

Testing

If all went well previously, you should be able to ping remote private network IP-addresses from each end. Example:

root@main-office:~$ ping 10.0.2.1
...
user@any-host-on-main-offixe:~$ ping 10.0.2.10
...

Troubleshooting

You should check that IPSec connection was succesfully established. Output from ipsec auto –status should end in something like following:

root@host:~$ ipsec auto --status
...
...
...
000 #9: "main-office-side-office":4500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 1034s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set

Or:

root@host:~$ ipsec auto --status
...
...
...
000 #22: "main-office-side-office":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 271s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set

Check that routing tables were setup. netstat -nr should output something like this:

root@host:~$ netstat -nr
Kernel IP routing table
Destination Gateway      Genmask        Flags  MSS Window irtt Iface
10.0.1.0    0.0.0.0      255.255.255.0  U        0 0         0 eth0
10.0.2.0    0.0.0.0      255.255.255.0  U        0 0         0 eth0
...
0.0.0.0     <defaultgw>  0.0.0.0        UG       0 0         0 eth0

Routing

If you happen to use different machine for creating your VPN tunnels than your default router, then you have to manually setup routes to match private networks. I won’t cover this case here, even though we use this kind of setup in our office. In very simple terms: you tell your default router to redirect all traffic send to external private network into your VPN router instead of trying to send it through your ISP:s router. Ofcourse your VPN router needs to have ip_forward on and so on. ‘tcpdump -n icmp’ is your friend when testing how far the traffic travels when testing connections with ping.

Leave a Reply

Your email address will not be published. Required fields are marked *


3 + six =