The MikroTik Security Guide and Networking with MikroTik: MTCNA Study Guide by Tyler Hart are available in paperback and Kindle!

MikroTik's EoIP tunnel functionality is very popular with users who need to extend Layer 2 networks between sites. It's configured much like a GRE tunnel and extends an OSI Layer 2 broadcast domain between sites. Once established the tunnel can be bridged to physical adapters or other connections. For applications or other systems that require a Layer 2 adjacency this is the only way to make it work across sites, other than using a dedicated provider circuit or fiber / microwave link.

EoIP is also a solution for quick-and-dirty network integration for two sites that have overlapping subnets that, for whatever reason, can't be completely readdressed. Small businesses and branch offices often have flat networks in the 192.168.0.0/24 or 192.168.1.0/24 ranges, and when the mandate comes down to enable communication between them quickly and cheaply, EoIP is a possible solution. There will need to be a little bit of compromise though, and the same rules that apply to a single network in one location now apply across locations. In the long-term readdressing networks to not overlap is ideal, but for small businesses with limited IT budgets and often no IT staff to speak of this is a solution that works for the short-term.

In this situation we have two small offices, one in St. Louis and the other in Norfolk. Both offices have LANs in the 192.168.1.0/24 subnet, and users need to be able to access resources in both offices remotely. Management doesn't understand what network addresses do or why they matter, and this task has to be done with minimal disruption of ongoing operations. Here is the network:

First we'll create the EoIP tunnels, then create the bridges that will connect them to the physical LAN, and lastly do a bit of IP readdressing.

Create the EoIP tunnel on St. Louis router and enable encryption:

/interface eoip add comment="To Norfolk" name="To Norfolk EoIP" remote-address=2.2.2.2 tunnel-id=0 ipsec-secret=jfvowev8rg844bg0

Create the EoIP tunnel on the Norfolk router and enable encryption:

/interface eoip add comment="To St. Louis" name="To St. Louis EoIP" remote-address=1.1.1.2 tunnel-id=0 ipsec-secret=jfvowev8rg844bg0

The tunnel ID numbers must match on each side. Additionally, an IPSEC key has been added, which will encrypt the EoIP traffic between the two sites. This is a good idea to have in place, but it is an optional step depending on your security needs, and it only works between Mikrotik devices. At this point you should see the tunnel come up and be active, though there probably isn't any traffic going over it. Here is the tunnel to the Norfolk side, just as an example:

You may have noticed the tunnel is running (R) in slave mode (S) because it has been bridged. We haven't completed that step yet, but we'll get to it. First we need to resolve a potential conflict.

Originally both routers had their LAN gateways set as 192.168.1.1 - not a big deal because they are separate. However, once we bridge the two LANs together it becomes a very big deal, because IP conflicts will wreak havoc. This is one of those compromises mentioned earlier; while we can have two locations sharing the same subnet, we can't have duplicate IP addresses between the locations. So on the Norfolk side the router's gateway IP address has been changed to 192.168.1.128, which doesn't conflict with the St. Louis router's gateway IP. Gateway address modifications would need to be made on the Norfolk side for devices that have static IPs to accommodate the change,

On the Norfolk router change the LAN gateway IP:

/ip address add address=192.168.1.128/24 interface=ether2

Another critical step that would have to be performed is splitting the DHCP scope on each side of the tunnel, so that the DHCP servers running on the Mikrotik routers aren't handing out duplicate client addresses. This step is unique to each organization and the DHCP scope(s) they are using. Once that is done we can move on to bridging interfaces to the EoIP tunnel.

Ether2 is our physical LAN interface on both routers, and we have to get traffic from the physical LAN interface to the EoIP tunnel, then out of the tunnel and into the physical LAN on the other side - easy to do with bridging. First we'll create the bridges, then add ports to them.

Create the bridge on the St. Louis router and add ports:

/interface bridge add name="EoIP Bridge"
/interface bridge port
add bridge="EoIP Bridge" interface=ether2
add bridge="EoIP Bridge" interface="To Norfolk EoIP"

Create the bridge on the Norfolk router and add ports:

/interface bridge add name="EoIP Bridge"
/interface bridge port
add bridge="EoIP Bridge" interface=ether2
add bridge="EoIP Bridge" interface="To St. Louis EoIP"

At this point we're done, other than testing. Let's do a bandwidth test from 192.168.1.1 in St. Louis to 192.168.1.128 in Norfolk:

While 120Mbps isn't exactly thrilling, this is done in a lab environment on virtual routers, and the graph shows consistent speed across two tests. That amount of bandwidth is probably enough to handle data between two small offices, and using larger Mikrotik Routers would allow for higher speeds. It should be noted, however, that this particular solution isn't scalable for larger flat networks, and pushing a consistently high volume of traffic is taxing for the CPU. Also, the overall speed across the EoIP tunnel is limited to the speed of the slowest WAN connection, so some testing will be needed to see if overall performance is acceptable in your environment.

Tyler Hart

Tyler Hart is a networking and security professional who started working in technology in 2002 with the US DoD and moved to the private sector in 2010. He holds a Business degree in IT Management, as well as the CISSP certification and others from Microsoft, CompTIA, Cisco, (ISC)2, Tenable Network Security, and more. For over 15 years he has worked and consulted with large and small organizations including hospitals and clinics, ISPs and WISPs, U.S. Defense organizations, and state and county governments.

Website