Home / Projects / Inter-DC/Multi-site Bridging/VPN Part …. Something. OpenVPN & Static Routing

Inter-DC/Multi-site Bridging/VPN Part …. Something. OpenVPN & Static Routing

This long overdue project finally got some love this weekend.   Over the past week, I struggled to get my existing Mikrotik VM’s to accept the things needed for this.   The most painful part was the SSL/Certificates part.  For some reason, the version I have just doesn’t work out well.  Since I do have the RB2011 still sitting here, I figured it was a good place to try it out on a spare IP, after all – this is its intended purpose in the colo.   How ever, due to reasons, I’m doing the connection in reverse as a proof of concept and validation of configuration.  It’ll require a whole new set up on my network – external and internal if it works.

So what I have here is the RB2011 sitting in the garage, on a public IP, with NAT on the default network that comes with the box.  Vanilla as missionary position.  We can call this point A.  On the other side is a 532 board with the same major release on it as the RB2011.  Its on an internal network, also with NAT on the box and some where else.  This is point B.

Now before we can do anything fun here, we need 3 things. SSL.  That sounds like one thing, but it requires 3 certs to work.  Firstly, a CA – imported and trusted by both routers.  Then, a Client and a Server certificate imported and trusted on each of the respective devices.  I used a guide and a linux box to set this up based on IP’s that are viewed by the opposing interface since hostnames aren’t expected to resolve in my case.

Well need to create a  profile and secrets to be used by the server and client.  This defines things like where/what to use for IP addresses, passwords, etc. Starting with the profile, I name it OVPN1 and provide a local IP address of  The remote address I have defined as an IP pool, which has  This is a user’s choice.  If you’re working with just 2 devices, then hard code the address.  That is the only setting here required to make this work.

Under the secrets section, we’ll create something new.  I named mine client1, and gave it the worlds weakest password – for the sake of testing.  I forced the option of ovpn for server and ovpn1 for the profile.  Here, you have the option of adding routes.  I’m going to leave this alone because that indicates layer3 traffic is going to get involved and I don’t want that to be my end goal.

Once that is done, we’ll need to create the ovpn server.  If you’re using winbox, this is under the PPP button, OVPN Server option near the top – not the add interface button.  Most things are straight forward. You can accepct most of the defaults, though I did force the m ode to IP, the certificate to server.crt_0 and the default profile to ovpn1. Checking “Enabled” and hitting apply makes this active.

Onto the client side. In a similar fashion, we’re going to create an openvpn client. Again in winbox, on the client, we go to PPP, but add interface> openvpn-client.  Change the name if you wish, but i left mine default.   The ‘dial out’ tab is where things are for us.  Here, we input the IP that we’re connecting to – for us that is the public IP of the server.  You’ll also need to give it your user name and password combo that we configured on the server. In my lab, I left the profile as default and had success but I did adjust the certificate to use the client.crt_0 entry. Everything else works as default.  On hitting enter, you should see a connected status.  In winbox, you should see that you now have an interface that as an IP address from the pool on the other side.  The caller ID should be the public IP of where ever your client is calling from.  You should also be able to open ping and hit the address that you gave the server interface as ‘local’. Remember, that address? Thats the one.

So, if we’re connected, we’ve mostly succeeded in our plans.  The bridge can talk to each sides of the bridge but that is where it stops.  To further validate the env, we’ll need to push a little hard.  The RB2011 already has a network on a bridged interface.  The remote side, Point B, does not.  The easiest thing to do here is to create a bridge, which I called loopback, and assign it an address.  For me, I chose on a /24 network.  On the server side, I added a static route for that network, reachable via the IP of the ovpn interface on the remote side.  This is the same address that Point B got from the IP pool on the server –  The remote network is reachable via the remote IP.  To complete this, on the remote side, I added a static route for reachable via  Again, from the device perspective – the remote network is reachable via the remote interface’s IP.

This enabled my pings from Point A to hit the networks of Point B, and the reverse.  This is all done via layer3 and with static routes.  This is not the end goal, how ever you can’t run a routing protocol on something thats layer3 only.  Now that this is here, we can move on to using VPLS to create a layer2 segment where we can push routes via OSPF.  That is for another time.

Point A config/print outs

[admin@fay10a] > interface ovpn-server server print
enabled: yes
port: 1194
mode: ip
netmask: 24
mac-address: FE:77:52:B0:32:76
max-mtu: 1500
keepalive-timeout: 60
default-profile: ovpn1
certificate: server.crt_0
require-client-certificate: no
auth: sha1,md5
cipher: blowfish128,aes128

[admin@fay10a] > ip address print
Flags: X – disabled, I – invalid, D – dynamic
0 ;;; defconf bridge
1 pu.bl.ic.ip/29 **.**.**.** ether1
2 D <ovpn-client1>

[admin@fay10a] > ppp profile print
Flags: * – default
0 * name=”default” use-mpls=default use-compression=default use-encryption=default only-one=default change-tcp-mss=yes use-upnp=default
address-list=”” on-up=”” on-down=””

1 name=”ovpn1″ local-address= remote-address=ovpn-pool use-mpls=default use-compression=default use-encryption=default
only-one=default change-tcp-mss=default use-upnp=default address-list=”” on-up=”” on-down=””

[admin@fay10a] > ip route print
Flags: X – disabled, A – active, D – dynamic, C – connect, S – static, r – rip, b – bgp, o – ospf, m – mme,
B – blackhole, U – unreachable, P – prohibit
0 A S **.**.**.** **.**.**.** 1
1 ADC ether1 0
2 ADC <ovpn-client1> 0
3 ADC bridge 0
4 A S 1



Point B config/print outs

[admin@point b] > interface ovpn-client print

Flags: X – disabled, R – running
0 R name=”ovpn-client2″ mac-address=FE:F7:F2:54:69:D6 max-mtu=1500 connect-to=pu.bl.ic.ip port=1194 mode=ip user=”client1″
password=”********” profile=default certificate=none auth=sha1 cipher=blowfish128 add-default-route=no

[admin@point b] > interface print
Flags: D – dynamic, X – disabled, R – running, S – slave
0 R ether1 ether 1500 1600 00:0C:42:09:8E:E3
1 ether2 ether 1500 1600 00:0C:42:09:8E:E4
2 ether3 ether 1500 1600 00:0C:42:09:8E:E5
3 R loopback bridge 1500 65535 00:00:00:00:00:00
4 R ovpn-client2 ovpn-out 1500 FE:F7:F2:54:69:D6

[admin@point b] > ip add print

Flags: X – disabled, I – invalid, D – dynamic
0 D xx.xx.xx.xx/23 xx.xx.xx.0 ether1
1 loopback
2 D ovpn-client2

[admin@point b] > ip route print
Flags: X – disabled, A – active, D – dynamic, C – connect, S – static, r – rip, b – bgp, o – ospf, m – mme,
B – blackhole, U – unreachable, P – prohibit
0 ADS 1
1 ADC xx.xx.xx.xx/23 xx.xx.xx.xx ether1 0
2 ADC ovpn-client2 0
3 A S 1
4 ADC loopback 0




About Ashley Young

I'm a North Carolina transplanted girl reaching my 30's. A few years ago, I procured my first DSM that would eventually mature many of my skills. This website is dedicated to the stories, adventures, and lessons that the car has brought to me over the years.

Leave a Reply

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


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll To Top