Skip to content
 

Vyatta OpenVPN Site-to-Site from Behind NAT or Firewall

Vyatta allows several methods for establishing site-to-site VPNs, namely IPSec and OpenVPN.  IPSec is probably the most efficient of the two protocols as it operates at Layer 2 however in most cases it requires both endpoints to be able to see each other.  What about establishing a vpn connection between two hosts, where one host is hidden behind NAT or a firewall?  OpenVPN can accomplish this with ease, at the small performance cost of being a Layer 7 protocol.

Vyatta allows you to configure OpenVPN in two ways; Remote Access and Site-to-Site (there is actually a third option, but I believe at writing this is a subscription only method).  Remote Access is designed for “Road Warrior” setup’s where a remote PC user needs to access a network, and operates in a one-to-many topology.  It only allows routing of subnets on the server side.  Site-to-Site, as the name suggests, allows you to connect 2 remote routers together, and allows routing of subnets on both ends.

OpenVPN uses two different forms of authentication; pre-shared key(PSK), or TLS mode using certificates (Public Key Infrastructure or PKI).  I tend to prefer using TLS mode but this requires additional steps which I will cover in my next article.  Here we will use a pre-shared key.

Configuration Lab

The following is a complete lab that will walk you through configuring an OpenVPN Site-to-Site VPN using two Vyatta routers (router-1 and router-2).  We will also configure a third vyatta router (nat-fw) to act as the NAT Firewall.  I suggest using a VMware Workstation team, or an ESXi server to create your topology.

Above is the topology we will be using.  Router-1 is “Internet” facing and Router-2 is sitting behind a NAT firewall that allows outbound connections.

NOTE: I will outline below all configuration required to get this lab up and running.  If you are just interested in the OpenVPN stuff, skip to the “Generating Pre-Shared Key” section.

Lab Pre-configuration

The following commands should be run on each respective router in your lab prior to proceeding with any of the OpenVPN configuration.

Router-1

set system hostname router-1
set interfaces ethernet eth0 address 10.0.0.1/24
set interfaces ethernet eth0 description "Router-1 WAN"
set interfaces ethernet eth1 address 192.168.100.1/24
set interfaces ethernet eth1 description "Router-1 LAN"
set service nat rule 10 outbound-interface eth0
set service nat rule 10 source address 192.168.100.1/24
set service nat rule 10 type masquerade
commit

Router-2

set system hostname router-2
set interfaces ethernet eth0 address 192.168.15.22/24
set interfaces ethernet eth0 description "Router-2 WAN"
set interfaces ethernet eth1 address 192.168.200.1/24
set interfaces ethernet eth1 description "Router-2 LAN"
set service nat rule 10 outbound-interface eth0
set service nat rule 10 source address 192.168.200.1/24
set service nat rule 10 type masquerade
commit

NAT Firewall

set system hostname nat-fw
set interfaces ethernet eth0 address 10.0.0.2/24
set interfaces ethernet eth0 description "NAT-FW WAN"
set interfaces ethernet eth1 address 192.168.15.1/24
set interfaces ethernet eth1 description "NAT-FW LAN"
set service nat rule 10 outbound-interface eth0
set service nat rule 10 source address 192.168.15.1/24
set service nat rule 10 type masquerade
commit

If everything is configured correctly, router-2 should be able to ping router-1′s WAN interface (10.0.0.1).

Generating Pre-Shared Key

Now that we have our lab prepared, the first things first we need to do is generate our pre-shared key:

vyatta@router-1:~$ vpn openvpn-key generate /etc/openvpn/key.psk
vyatta@router-1:~$ ls -l /etc/openvpn/key.psk
-rw------- 1 root root 636 Oct 17 19:05 /etc/openvpn/key.psk

This generates a file (/etc/openvpn/key.psk) that both systems will use to verify each other’s identity prior to establishing the VPN connection.  Thus we need to copy it from router-1 to router-2 via secure means.  I would suggest using Secure Copy (SCP) from router-2.  In order to do this we need to configure router-1 with an SSH server.  Note that the file created is owned and readable by root only, so our ssh server will need the “allow root” option, and we will need to provide a password for the root account.  From configuration mode, execute the following commands:

set service ssh
set service ssh allow-root
set system login user root authentication plaintext-password [PASSWORD]
commit

Now from router-2 we need to copy our key.psk file from router-1 using SCP.  As the file needs to be owned by root, we need to sudo on router-2 prior to running SCP:

vyatta@router-2:~$ sudo -s
root@router-2:~# scp 10.0.0.1:/etc/openvpn/key.psk /etc/openvpn/key.psk
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is bb:0d:48:3d:13:61:71:60:d2:13:7b:c9:cc:a7:52:d9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.1' (RSA) to the list of known hosts.
Welcome to Vyatta
root@10.0.0.1's password:
key.psk                                       100%  636     0.6KB/s   00:00
root@router-2:~# ls -l /etc/openvpn/key.psk
-rw------- 1 root root 636 Oct 17 19:15 /etc/openvpn/key.psk
That’s it!  We now have our pre-shared key on both routers and are ready to configure our site-to-site OpenVPN.  As mentioned earlier, I’ll do a follow-up post using TLS PKI certificates.

Router-1 Configuration

Run the following configuration commands on router-1:

set interfaces openvpn vtun0
set interfaces openvpn vtun0 mode site-to-site
set interfaces openvpn vtun0 local-address 172.16.100.1
set interfaces openvpn vtun0 remote-address 172.16.100.2
set interfaces openvpn vtun0 shared-secret-key-file /etc/openvpn/key.psk

Your configuration should look something like this:

vyatta@router-1# show interfaces openvpn
 vtun0 {
     local-address 172.16.100.1
     mode site-to-site
     remote-address 172.16.100.2
     shared-secret-key-file /etc/openvpn/key.psk
 }

One important thing to note is that I have not included a “remote-host” configuration item for router-1.  This is because router-1 cannot directly communicate with router-2, thus the “remote-host” entry would be useless.  Router-2 will be responsible for initiating the OpenVPN connection.

Router-2 Configuration

For router-2 we will have essentially the same configuration with local and remote addresses being reversed, but we will also use the previously mentioned remote-host entry. This attribute will accept either an IP address, or a DNS name (great for DynDNS configurations!). Run the following configuration commands on router-2:

set interfaces openvpn vtun0
set interfaces openvpn vtun0 mode site-to-site
set interfaces openvpn vtun0 local-address 172.16.100.2
set interfaces openvpn vtun0 remote-address 172.16.100.1
set interfaces openvpn vtun0 remote-host 10.0.0.1
set interfaces openvpn vtun0 shared-secret-key-file /etc/openvpn/key.psk

Your configuration should look something like this:

vyatta@router-2# show interfaces openvpn
 vtun0 {
     local-address 172.16.100.2
     mode site-to-site
     remote-address 172.16.100.1
     remote-host 10.0.0.1
     shared-secret-key-file /etc/openvpn/key.psk
 }

Once we enter “commit”, router-2 will automatically try to establish an OpenVPN connection with router-1.  If successful, you should be able to ping 172.16.100.1 (router-1′s vtun0 address) from router-2, and vice versa.

Static Routes

Finally, in order for our respective router’s LAN subnets to be able to communicate, we need to configure static routes on both routers, telling each where to find each other’s subnets:

Router-1

set protocols static route 192.168.200.0/24 next-hop 172.16.100.2
commit

Router-2

set protocols static route 192.168.100.0/24 next-hop 172.16.100.1
commit

You should now be able to ping 192.168.200.1 from Router-1, and 192.168.100.1 from Router-2.  Congratulations! You have successfully configured a Site-to-Site OpenVPN connection from behind a NAT firewall.

Troubleshooting

You can watch the VPN nodes establish connections, as well as view any errors or problems by using the “tail -f /var/log/messages” command.  For example, here is what a successful connection should look like:

vyatta@router-2:~$ tail -f /var/log/messages
Oct 17 19:50:20 vyatta openvpn[8610]: Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Oct 17 19:50:20 vyatta openvpn[8610]: Local Options hash (VER=V4): '2e1fe9d6'
Oct 17 19:50:20 vyatta openvpn[8610]: Expected Remote Options hash (VER=V4): '57bb0ab0'
Oct 17 19:50:20 vyatta openvpn[8623]: Socket Buffers: R=[112640->131072] S=[112640->131072]
Oct 17 19:50:20 vyatta openvpn[8623]: UDPv4 link local (bound): [undef]
Oct 17 19:50:20 vyatta openvpn[8623]: UDPv4 link remote: [AF_INET]10.0.0.1:1194
Oct 17 19:50:24 vyatta openvpn[8623]: Peer Connection Initiated with [AF_INET]10.0.0.1:1194
Oct 17 19:50:25 vyatta openvpn[8623]: Initialization Sequence Completed

Stay tuned for my next article on configuring TLS certificate based authentication for OpenVPN, using the easyrsa scripts.

Also, shout-out to Roggy for the original client/server idea that led me down this path! Take a look at his original post here: http://roggyblog.blogspot.com/2010/03/managed-service-provider-using-vyatta.html.

14 Comments

  1. dmbaturin says:

    Yes, the great advantage of OpenVPN is that it works even in restrictive environments.
    The only note: IPsec operates at L3 (network), not L2 (mistype, I assume).
    Added your website to our unofficial vyatta wiki, by the way (http://wiki.het.net/wiki/Vyatta_related_websites).

  2. Botto says:

    Nice tutorial on generating PSK and copying to peer via SCP. Vyatta documentation doesn’t explain this part very well. I have been trying to set up site to site Open VPN & I think you have just made my day………

    • Adam says:

      Haha no problem. If you’re going to be doing a few sites and client/server, I strongly recommend PKI configuration. I’ll get around to writing up an article soon enough. I’ve been side tracked with upgrading my SAN (hence the recent postings).

  3. Botto says:

    Hey! This part didn’t work in my lab setup:
    “If everything is configured correctly, router-2 should be able to ping router-1?s WAN interface (10.0.0.1).”

    Am currently using virtual box. However I figured out that I should add this line on router-2:
    router-2# set system gateway-address 192.168.15.1

    …and it worked wonders!

    Everything else works including pinging the remote subnets & interfaces (192.168.200.1 & 192.168.100.1). However the:
    vyatta@router-2:~$ tail -f /var/log/messages

    displays an input/output error! Please advice on what could be missing?

  4. [...] Vyatta OpenVPN Site-to-Site from Behind NAT or Firewall « Adam’s Tech Notes – [...]

  5. Pytha says:

    Thanks a lot for the part about making the keys the same…just what i needed…

    Cheers.

  6. John says:

    I am a bit confused. I was reading through a nat guide. In your scenario there is nat – nat – nat. What is the need for the middle nat?
    http://cognitiveanomalies.com/cisco-nat-how-nat-works/
    I looked through the cisco site and I did not find anything like this.
    Am I just confused or is there no need for the firewall in the middle and it is only for the setup part of it?
    Very nice guide you have.

    • adam says:

      The purpose of this article is to demonstrate how to configure an OpenVPN from behind a NAT firewall of some kind, most likely one you don’t have control or access to. The middle router is there to simulate this.

  7. kk says:

    why are your Vtuns /32 !!

    • Adam says:

      An OpenVPN site-to-site link is refered to as a point-to-point link. This is a special case where you are not really creating a network per se, instead you are simply assinging the remote “end point” of the link. With a point to point link, when you put packets into the start of the tunnel, the only place it can come out is the end of the tunnel, there are no other hosts IP’s needed in this case. Because there is literally no-where else for the packet to go, a /32 is used.

      Now, if you were using an ethernet link instead of a Vyatta point-to-point link, the smallest network you could use is a /30 which has 2 hosts, a broadcast and a network address.

  8. Botto says:

    Hi Adam, What about firewall rules for the openvpn tunnel as well as for the internet. I have been working on this but to no avail. My internet firewall on the s2s routers blocks the open vpn traffic.

  9. Botto says:

    Have you tried dynamic routing with ospf? Would this scenario work with a /32 or /30?

Leave a Reply