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.


  • 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: <->
    • ok: <->
    • ok: <->
    • not ok: <->
    • not ok: <->
  • install Openswan on every server (apt-get install openswan)

Example setup

We have two private networks, let’s say is our main office network and is our side office network. Main office server has public IP-address and side office server has public IP-address Main office server has private IP-address and side office has private IP-address 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



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


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


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

# main office (left) <-> side office (right) -vpn
conn main-office-side-office
    # public ip
    # optionally, if fqdn is not set, put public ip here
#    leftid=
    # private network address on this machine
    # private network
    # usually public ip address of right
    # left rsa-key (previously shown how to obtain)

    # public ip
    # same here, if no fqdn is set, use public ip
    # usually public ip address of left
    # right rsa-key


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
user@any-host-on-main-offixe:~$ ping


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  U        0 0         0 eth0  U        0 0         0 eth0
...     <defaultgw>        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.

Leave a Reply

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