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.
- 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)
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 18.104.22.168 and side office server has public IP-address 22.214.171.124. 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.
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=.............................
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=126.96.36.199 email@example.com # optionally, if fqdn is not set, put public ip here # leftid=188.8.131.52 # 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=184.108.40.206 # left rsa-key (previously shown how to obtain) leftrsasigkey=... # public ip right=220.127.116.11 # same here, if no fqdn is set, use public ip firstname.lastname@example.org rightsourceip=10.0.2.1 rightsubnet=10.0.2.0/24 # usually public ip address of left rightnexthop=18.104.22.168 # 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 ...
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 ...
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
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
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.