Vyatta / VyOS: site-to-site OpenVPN + Open Shortest Path First (OSPF) setup
When you scale your network from one location to another, sooner or later you may want to merge those networks and have only one. To merge networks, you need to setup 2 routers and site-to-site connection between them. One of open source solutions is OpenVPN and Vyatta/VyOS. This article will cover setting up site-to-site connection with OpenVPN. I will assume you have already setup your Vyatta/VyOS router so it has basic internet connection and some LAN behind it.
Before you start setting things up you might want to consider few things:
- First of all, do we have different networks on these 2 sites ? We don’t want to merge same network ranges into one, since we might run into troubles. Consider setting networks logically, so you will know exactly where packets are originating from. Example: 192.168.100.0/24 (Site A) and 192.168.101.0/24 (Site B) (I will take these ranges for my example setup)
- Second, we should consider using one pool of ip’s for VPN gateway ip’s, on which they will communicate with each other, for easy adding of possible future new VPN sites. Example: 172.16.0.0/16
- Third, if we are connecting 3 or more sites, we may want to consider cross connecting them with each other, so that our network will still see other networks even though one site lost internet connection. We don’t want single points of failure.
- Last but not least, to make OSPF work, our Vyatta/VyOS router has to be default gateway for all our LAN computers/servers
As prerequisite to configuring site-to-site with OpenVPN we need to generate a special key, that will serve as authentication between two sites. To generate such key we should log into Site A router and type:
vpn openvpn-key generate /config/auth/site_A_siteB_key.psk
Note: VyOS changed this command for consistency and you have to run:
run generate openvpn key /config/auth/site_A_siteB_key.psk
Site-to-site OpenVPN tunnel
To setup site-to-site VPN enter these commands on Site A router:
set interfaces openvpn vtun1 local-address 172.16.4.1 set interfaces openvpn vtun1 local-host xxx.xxx.xxx.xxx set interfaces openvpn vtun1 local-port 10001 set interfaces openvpn vtun1 mode site-to-site set interfaces openvpn vtun1 protocol udp set interfaces openvpn vtun1 remote-address 172.16.4.2 set interfaces openvpn vtun1 remote-host yyy.yyy.yyy.yyy set interfaces openvpn vtun1 remote-port 10001 set interfaces openvpn vtun1 shared-secret-key-file /config/auth/siteA_siteB_key.psk
Replace xxx.xxx.xxx.xxx with Site A router’s public ip and yyy.yyy.yyy.yyy with Site B router’s public ip, on which we want to connect routers. For Site A‘s VPN gateway we chose ip 172.16.4.1 and for Site B: 172.16.4.2
Now we have our Site A router trying to connect to Site B, but we haven’t configured Site B yet. To setup Site B, we need to first copy the .psk key to exact same location as on Site A‘s router. Best way is just to scp it to new router:
[email protected]:~$ sudo -s [email protected]:~# scp /config/auth/siteA_siteB_key.psk [email protected]:/config/auth/siteA_siteB_key.psk
Now we need to setup Site B which is almost exactly the same, except we switch the ip’s around:
set interfaces openvpn vtun1 local-address 172.16.4.2 set interfaces openvpn vtun1 local-host yyy.yyy.yyy.yyy set interfaces openvpn vtun1 local-port 10001 set interfaces openvpn vtun1 mode site-to-site set interfaces openvpn vtun1 protocol udp set interfaces openvpn vtun1 remote-address 172.16.4.1 set interfaces openvpn vtun1 remote-host xxx.xxx.xxx.xxx set interfaces openvpn vtun1 remote-port 10001 set interfaces openvpn vtun1 shared-secret-key-file /config/auth/siteA_siteB_key.psk
Okay now we should tail our /var/log/messages on one router, to make sure tunnel is successfully established. We can verify successfully established tunnel by pinging from Site A Site B‘s local ip and the other way around. So on Site A we would type: ping 172.16.4.2 and on Site B we should type: ping 172.16.4.1 If we got our packets, we have successfully established tunnel and everything went smooth.
Tailing should return us something similar to this:
Jan 18 09:50:20 vyatta openvpn[8610]: Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ] Jan 18 09:50:20 vyatta openvpn[5502]: Local Options hash (VER=V4): '2e1fe9d6' Jan 18 09:50:20 vyatta openvpn[5502]: Expected Remote Options hash (VER=V4): '57bb0ab0' Jan 18 09:50:20 vyatta openvpn[5516]: Socket Buffers: R=[112640->131072] S=[112640->131072] Jan 18 09:50:20 vyatta openvpn[5516]: UDPv4 link local (bound): [undef] Jan 18 09:50:20 vyatta openvpn[5516]: UDPv4 link remote: [AF_INET]172.16.4.1:10001 Jan 18 09:50:24 vyatta openvpn[5516]: Peer Connection Initiated with [AF_INET]172.16.4.1:10001 Jan 18 09:50:25 vyatta openvpn[5516]: Initialization Sequence Completed
Setting up OSPF with policies
Now that we see each other, we want to set up OSPF to propagate routes from one router to another. To do that, we first need to setup some policies that we will use afterwards with OSPF to make sure we propagate only ip ranges based on RFC flagged as private. Make sure you entered these on both routers:
set policy prefix-list RFC1918PREFIXES rule 1 action permit set policy prefix-list RFC1918PREFIXES rule 1 le 32 set policy prefix-list RFC1918PREFIXES rule 1 prefix 10.0.0.0/8 set policy prefix-list RFC1918PREFIXES rule 2 action permit set policy prefix-list RFC1918PREFIXES rule 2 le 32 set policy prefix-list RFC1918PREFIXES rule 2 prefix 172.16.0.0/12 set policy prefix-list RFC1918PREFIXES rule 3 action permit set policy prefix-list RFC1918PREFIXES rule 3 le 32 set policy prefix-list RFC1918PREFIXES rule 3 prefix 192.168.0.0/16
We should make route map of these prefixes, permit them and drop the rest:
set policy route-map ONLYRFC1918PREFIXES rule 10 action permit set policy route-map ONLYRFC1918PREFIXES rule 10 match ip address prefix-list RFC1918PREFIXES set policy route-map ONLYRFC1918PREFIXES rule 90 action deny
Finally we can setup our OSPF:
set protocols ospf area 172.16.0.0 authentication md5 set protocols ospf area 172.16.0.0 network 172.16.4.0/30 set protocols ospf redistribute connected metric-type 2 set protocols ospf redistribute connected route-map ONLYRFC1918PREFIXES
Once we have set this up, we should check we can ping internal ip of computer in Site A from computer in Site B. Make sure on both routers you have all-ping enabled in firewall rule. If ping goes thru, everything worked and you have successfully set up site-to-site VPN and OSPF.
Similar posts:
Nice tuto and thank.
I want to use dynamic dns instead of xxx.xxx.xxx.xxx or yyy.yyy.yyy.yyy for local and remote host what can I do?
thank you
Look at tinc vpn. You can use dynamic dns
I don’t think that is possible. There is no option to dynamically set ip for site-to-site tunnel. Either way, both ends would have to know about the new ip… so basically you need static ip on both sides.
What you could do is setup openvpn server on some VPS (remote site) and then make normal VPN client connection from site1 and site2 to it, then set openvpn server to disable client isolation. You could then basically push static routes on both clients, to have both networks availiable.
can you share me the topology??
It’s been a while since I wrote this post… but it should be like this: https://blackbird.si/wp-content/uploads/2015/06/ospf.jpg
thank you
Howdy,
I noticed a typo that cost me a few minutes of headscratching:
set policy prefix-list RFC1918PREFIXES rule 1 action permit
set policy prefix-list RFC1918PREFIXES rule 1 le 32
set policy prefix-list RFC1918PREFIXES rule 2 prefix 10.0.0.0/8 <<< TYPO HERE; SHOULD BE rule 1
set policy prefix-list RFC1918PREFIXES rule 2 action permit
set policy prefix-list RFC1918PREFIXES rule 2 le 32
set policy prefix-list RFC1918PREFIXES rule 2 prefix 172.16.0.0/12
set policy prefix-list RFC1918PREFIXES rule 3 action permit
set policy prefix-list RFC1918PREFIXES rule 3 le 32
set policy prefix-list RFC1918PREFIXES rule 3 prefix 192.168.0.0/16
Thanks much for the guide. This was extremely helpful.
Oh! Sorry about that. I fixed it now.
Hi,
I’m getting the error in the OSPF part.
# set protocols ospf area 172.16.0.0 redistribute connected metric-type 2
Configuration path: protocols ospf area 172.16.0.0 [redistribute] is not valid
Set failed
Please help!!
I see the problem. There was a typo. Please check that part of configuration again. I fixed it in the post.
It should look similar to this:
This is super helpful – thanks very much. For the total layman, one thing that would help is at the end – I’m not clear which router I’m supposed to be entering the OSPF policies in – both?
Also, for those of us still grasping at the concepts, I’d like to confirm that the purpose of creating the routing table for local addy space, and only propagating these routes, is to *not* override the remote routers route to the net?
I realize that all probably seems obvious, so thanks very much for any clarifications.
Finally – any observations about how this configuration can be expanded to treat, i.e. a multi-tenant environment, each with several offices organized into their own ospf areas would be killer. Oh.. and a pony – I’ve always wanted one, so if you can throw that in too it would be great!
But seriously – very helpful starting point, and I’ve been looking!
To answer your question, yes. OSPF policies should be entered on both routers. And yes, it’s a good practice to make sure that only internal networks get propagated thru OSPF – it is interior routing protocol after all.
I will fix howto, so it’s more clear that rules should be applied on both routers.
I can’t really help you with more complex environment, but since you have the basics here, it shouldn’t be too hard to expand it to multiple routers etc. It’s basically the same procedure for each… Create a small virtualbox environement with couple of Vyos routers and try it out.
As of pony: https://blackbird.si/wp-content/uploads/2015/12/pony.png
Hi Alen,
I tried to setup OSPF but without successful. I am using vyOS and Ubiquiti Router.
I set up policy-prefix, route-map and nothing. Of course VPN site-to-site works corectly. I am able to ping gateway on second side, but other computer not.
Site A: local-address: 10.20.14.2, network 10.10.0.0/16
Site B: local-address: 10.20.14.1, network 10.14.0.0/16
If I set static route it works.
Do you know where is the problem?
Thank you!
Hi Alex, thanks for the great post!
Curious, the docs say “Exactly one comparison (ge, le, or prefix) may be specified for a prefix list rule”, but you have both `prefix` and `le`. It seems like the `le` comparison should be removed, no?
It’s been quite a while since I’ve written this article, but I know I copied this part from official documentation and didn’t really pay attention to it, but according to this: http://www.brocade.com/content/html/en/vrouter5600/35r6/vrouter-35r6-routingpolicies/GUID-7F8EE985-082F-4517-9995-CD4686655C51.html they do use prefix + le. It could be that this `le` is just `bloat` and could be removed… You should maybe ask official support about this.