How to bridge distant networks using RouterOS and PPtP
Mikrotik has recently added MPLS to their already amazing RouterOS product. MPLS offers some really nice options for bridging networks that exist within a single administrative domain. But, what can you do if you need to bridge 2 networks that do NOT exist within the same administrative domain? This article discusses how to create a bridge using another fairly recent upgrade in RouterOS. Read on…
Consider the following network:
What this article will attempt to explain is the process needed to bridge LAN1 and LAN2. We will accomplish this task by building a tunnel (PPtP in this example) over the internet and then creating a bridge on each router (Router1 and Router2) that includes the tunnel endpoints as well as an ethernet port on each end. There are numerous ways to accomplish this task (I have another example in this blog post), however this method is among the easiest AND offers a couple of real advantages over the method mentioned in the earler blog post. The primary advantage to this method is that it gives us the ability to carry packets that are MUCH larger than what is available using EoIP. EoIP is limited to an MTU of 1500 bytes. With the PPtP bridge, we can have an MTU of over 65000!
First, we just need to configure the 2 routers for basic internet service. I won’t detail that configuration here, but you should be able to log into either router and ping the other public IP (12.12.12.1 and 24.24.24.1 in this example). The next step is to configure the tunnel itself. On the server side, we need to configure the pptp service. This is done with the following command (on router1 only):
/interface pptp-server server
set default-profile=default-encryption enabled=yes mrru=65535
Note that I set the mrru value. Because of the way this works, all clients will need to have this MRRU set the same. Another thing to note is that 10/100M ethernet only has an MTU of 1500 bytes, so setting this value to 65535 does nothing for 10/100 networks.  Also note that the default MTU for the tunnel can be set to whatever the actual transport will carry. What this MRRU value does is configure the ppp protocol to transport packets of any size (up to the mrru value) even if the underlying transport (where the tunnel will traverse) uses a smaller MTU. Of course, it will be fragmenting and reassembling the packets on both ends.
Our next task is to create the bridge. Since we want to bridge ether2 with the tunnel, we will be adding ether2 into the bridge in this step. THIS WILL NEED TO BE DONE ON BOTH ROUTERS. Do this as follows:
/interface bridge add name=lanbridge
/interface bridge port
add bridge=lanbridge interface=ether2
NOTE: In order to be proper about how we configure the network, you should also move the IP addresses that are assigned to ether2 over to the bridge. If you have firewall rules that manage traffic on ether2, you need to configure the bridge to use the IP firewall (/interface bridge settings set use-ip-firewall=yes) and change those rules to look for the interface “lanbridge” OR “in-bridge-port=ether2”. Other configuration changes that MAY be necessary includes DHCP server interfaces and queues. You get the idea.
You probably noticed that we did not add anything referencing the tunnel when we added ports to the bridge. If you did NOT notice, go back and look, because we didn’t. :-) The reason for this is due to the fact that we will be DYNAMICALLY adding interfaces to the bridge. On router1 (the server side) we configure the profile and secret as follows:
/ppp profile
set default-encryption bridge=lanbridge change-tcp-mss=yes local-address=192.168.25.1 \
use-compression=yes use-encryption=yes use-vj-compression=no
/ppp secret
add disabled=no name=router2 password=router2pass profile=default-encryption \
remote-address=192.168.25.2 service=pptp
Some things to note about the above configuration. I chose to set the local IP in the profile and the remote IP in the secret. It is not important WHERE you set these values, however they must be set somewhere. That tutorial is the subject matter for another day. The bridge selection is important. With that setting enabled, the RouterOS will automatically (dynamically) add any new ppp (pptp, pppoe, ppp, l2tp, etc.) interface that uses the profile to the selected bridge. I configured a username/password (router2/router2pass) for the remote router and instructed the pptp server to use the profile called “default-encryption” (which includes the bridge configuration) for this user’s connection. With the above configuration set in router1, we are finished with that side.
All that’s left is the set up the router2 side. Remember, the bridge and ports were already done on that router, so all that remains is the tunnel and profile. That is done as follows:
/ppp profile
set default-encryption bridge=bridge1 change-tcp-mss=yes use-compression=yes use-encryption=yes use-vj-compression=no
/interface pptp-client
add connect-to=12.12.12.1 disabled=no mrru=65535 name=tunnel1 \
password=router2pass profile=default-encryption user=router2
Here we set the profile again to use the bridge1. NOTE that we do NOT set IP addresses in the profile on the client side. This is controlled at the server side. We set the client to connect to the server at it’s public IP of 12.12.12.1, configure the mrru to be the same as we set the server and name the tunnel (not needed, but I really dislike the default name of “pptp-out1”).
Once this configuration is complete, you will notice that the ports have been automatically added to the bridge (winbox: Bridge->Ports). You should be aware that if you run a DHCP server on either side, it will be visible by devices at BOTH sides. Configuring devices manually, or using static lease entries is recommended. If you want ALL traffic from LAN2 to use the LAN1 router as a default gateway (or the other way around), it is easy to set up. Also note, that this configuration will behave just like you have 2 switches bridged (connected with an ethernet cable). IP space MUST be managed accordingly. This configuration will pass DHCP, vlan tags, broadcast and any other type of packet.
Please “Digg” this article if you find it useful. Feel free to leave comments on other uses you find for this configuration.
April 18th, 2011 at 6:16 pm
Thanks for this Butch, it is an awesome example! I’ve replicated the example on my own infrastructure, but I’m getting a weird issue.
My PPTP connects correctly, my bridge has been configured and the pptp ports are dynamically added as per the example.
However, when attempting to ping hosts on either side of the bridge (using the winbox tools>>ping command on either router), I can only ping hosts if I specify the pptp interface to send the ping out of. If I specify any other interface (ether2 or bridge) the ping times out..
Do you know what could be the cause of this? I’m using 2 x routerOS 5.1 installations on ESX vm’s.
May 21st, 2012 at 5:11 am
Hi,
Thanks for this great article! It really helps understand bridging networks over PPTP.
However, I’d like to ask, is it possible to use this same scenario for remote clients, that need to login remotely to their home network, using some client side software for PPTP tunneling. The difference in this scenario is that we don’t have the 2nd router (router2), but instead we have a dynamically created connection, initiated by a remote client. What would change in this configuration shown above?
Thanks.
November 13th, 2012 at 5:01 am
followed your instruction, i can ping computer on lan side on router 1 from lan side of router2, ping google, but i cant surf the web. Any idea?