GRE Tunnel
The MikroTik Security Guide and Networking with MikroTik: MTCNA Study Guide by Tyler Hart are available in paperback and Kindle!
GRE (Generic Route Encapsulation) is a basic Layer 3 tunneling protocol, and the foundation for other technologies and solutions like PPTP and GRE over IPSEC. Unlike IPSEC tunnels, GRE creates virtual interfaces that we can add IP addresses to and use for proper routing and routing protocols. These tunnels function a lot like EoIP tunnels, but present connectivity at a different layer. GRE also has fairly low CPU and RAM requirements, but that comes with a caveat - it's unencrypted by default. Recently Mikrotik introduced functionality that allows IPSEC encryption to be added to GRE tunnels in a turnkey way, but that only works Mikrotik-to-Mikrotik.
If requirements like HIPAA or PCI specify that traffic must be encrypted then check out GRE over IPSEC if your network environment isn't homogeneous.
Let's look at a typical topology in use - two offices, Seattle and Boise, both connected to the Internet. Each office has a router and a static IP address:
Mikrotik GRE Topology
You can see the physical and logical topology. The GRE tunnel will create a tunnel interface on each router, and behave like a dedicated circuit between the routers. A host on the Seattle LAN tracerouting to a host on the Boise LAN will only see two hops - the Seattle router gateway, the Boise router, and that's it. Whatever service provider routing that's happening across the WANs will be transparent to internal hosts - they will only see the GRE tunnel.
First, we'll add the static, public IPs of each router to an address list that a firewall rule can use. On each router:
/ip firewall address-list add address=87.16.79.2 comment=Boise list="Trusted IPs" add address=165.95.23.2 comment=Seattle list="Trusted IPs"
Then we'll add a firewall Input rule that allows GRE traffic from each of those trusted IP addresses, because they belong to the organization and we own them. We'll also add a rule allowing input from the IP address that will get put on the virtual GRE interfaces once they are created. On each router:
/ip firewall filter add chain=input comment="Allow Input; Trusted IPs List" protocol=gre src-address-list="Trusted IPs" /ip firewall filter add chain=input comment="Allow Input; GRE Subnet" dst-address=192.168.1.0/30
This will allow the GRE packets from each of the trusted IPs into the other respective router, allowing the tunnel to be established. GRE doesn't use a pre-shared key or any kind of authentication, it's a very basic protocol. This is why we put a firewall rule in to restrict traffic to our own trusted addresses.
On each router we'll build one half of the GRE tunnel, each router pointing at the other's public IP address. We'll also add a comment on each entry to show where it's going to, so that the tunnels are easily identifiable if you have multiple. Additionally, a robust IPSEC secret key is added to encrypt the traffic - this is an optional step.
On the Seattle router:
/interface gre add comment=Boise !keepalive name=Boise remote-address=87.16.79.2 ipsec-secret=8tu39yt93h5g93yt93hi0
On the Boise router:
/interface gre add comment=Seattle !keepalive name=Seattle remote-address=165.95.23.2 ipsec-secret=8tu39yt93h5g93yt93hi0
At this point you have a functioning tunnel, but if you look in the routing table there isn't anything there. The tunnel is up, but there aren't any addresses on the virtual interfaces - no addresses, no traffic, no routing. We've created a point-to-point network and like any network it needs some addresses. So, we'll give each end of the interface an IP address inside a /30 subnet. You can see the IP addresses on the topology diagram above.
On the Seattle router:
/ip address add address=192.168.1.1/30 interface=Boise network=192.168.1.0
On the Boise router:
/ip address add address=192.168.1.2/30 interface=Seattle network=192.168.1.0
These IP addresses correspond with the second firewall rule we added above, allowing us to ping the 192.168.1.0/30 addresses on the virtual GRE interfaces. At this point if you check the routing table you'll now find a new network, but you won't be able to ping from one LAN subnet to another - we need to add some routes. You have two choices at this point - add static routes, or use a routing protocol. For the sake of brevity we will just add static routes, and cover OSPF in some other articles.
On the Seattle router:
/ip route add comment="Boise LAN" distance=1 dst-address=192.168.30.0/24 gateway=192.168.1.2
On the Boise router:
/ip route add comment="Seattle LAN" distance=1 dst-address=192.168.90.0/24 gateway=192.168.1.1
That's all we need to do a traceroute from one Seattle LAN IP to a Boise LAN IP and get a reply back:
Successful traceroute across the GRE tunnel
Notice that there are no hops across service provider WAN routers. As far as the LAN hosts are concerned they never left the collection of local networks, which is partially true; all traffic went through the tunnel, even though you and I know the tunnel was created over service provider connections. That's the magic of tunnels!
This is only a small scale demonstration of what GRE can do. You can very easily have multiple locations linked together in a hub-and-spoke or partial-mesh configuration, running a dynamic routing protocol like OSPF.
