Featured image for security/firewalls/antivirus topics

MikroTik GRE Tunnels: Configuration and Use Cases

Byadmin
Share
Tweet
Share
Pin
0 Shares

GRE is the tunnel protocol you reach for when a VPN alone will not do the job. It carries routing protocols across the internet, connects two private networks over a public link, and gives BGP peers a stable path independent of the underlying ISP topology. MikroTik GRE tunnel is simple to configure — the hard part is knowing where it fits and where it does not.

This guide covers GRE fundamentals, a full site-to-site configuration, real use cases from branch connectivity to BGP peering, GRE combined with IPsec for encryption, and the troubleshooting steps that catch the mistakes that break tunnels in production.

Table of Contents

  1. What GRE Is and When to Use It
  2. GRE vs. IPIP, EoIP, and IPsec
  3. Step-by-Step: Site-to-Site GRE Configuration
  4. Configure Keepalive to Detect Tunnel Failure
  5. MTU and Fragmentation
  6. Running a Routing Protocol Over GRE
  7. Encrypt GRE with IPsec
  8. Real-World Use Cases
  9. Firewall Rules for GRE
  10. Troubleshooting GRE Tunnels
  11. Quick-Reference Configuration Cheat Sheet
  12. Deployment Checklist
  13. Conclusion

What GRE Is and When to Use It

GRE (Generic Routing Encapsulation) wraps one IP packet inside another, creating a virtual point-to-point link between two routers over any IP network. The original packet passes through untouched inside the GRE header — only the outer addressing changes.

  • Protocol number. GRE runs as IP protocol 47, not TCP or UDP. Firewall rules and some NAT devices need explicit handling for this.
  • Stateless by design. GRE does not track session state. If the remote end goes down, traffic keeps routing into the tunnel and gets dropped silently, unless keepalive is configured.
  • No encryption or authentication. GRE only encapsulates. Anyone capturing the outer packets can read the encapsulated payload. Pair GRE with IPsec when confidentiality matters.
  • Carries more than IP. GRE supports multicast and routing protocol traffic that plain IP-in-IP tunnels cannot carry, which is why it works for OSPF and EIGRP-style deployments where IPIP falls short.
  • Fixed overhead. Every GRE packet adds 24 bytes of overhead: a 4-byte GRE header plus a 20-byte outer IP header. This overhead drives every MTU decision later in this guide.

GRE vs. IPIP, EoIP, and IPsec

Protocol Carries Encryption Best for
GRE IPv4, IPv6, multicast No (pair with IPsec) Routing protocols, BGP peering, multicast over WAN
IPIP IPv4 only No Simple point-to-point IPv4 tunnels, lower overhead than GRE
EoIP Full Ethernet frames No Bridging Layer 2 across sites, extending a VLAN over the internet
IPsec (tunnel mode) IP traffic Yes Confidentiality-first VPNs, no need for multicast or dynamic routing inside the tunnel

Pick GRE when you need to run a routing protocol, forward multicast, or maintain a stable Layer 3 path that does not care about the underlying route between endpoints. Pick IPsec alone when encryption is the only requirement and you do not need multicast or a dynamic routing protocol running through the tunnel.

Step-by-Step: Site-to-Site GRE Configuration

This example connects two sites: Site 1 with LAN 10.1.101.0/24, Site 2 with LAN 10.1.202.0/24, over public IP addresses 192.168.80.1 and 192.168.90.1.

1. Create the GRE interface on each router

# Router at Site 1
/interface gre add name=gre-to-site2 \
  local-address=192.168.80.1 remote-address=192.168.90.1

# Router at Site 2
/interface gre add name=gre-to-site1 \
  local-address=192.168.90.1 remote-address=192.168.80.1

2. Assign tunnel addresses

# Router at Site 1
/ip address add address=172.16.1.1/30 interface=gre-to-site2

# Router at Site 2
/ip address add address=172.16.1.2/30 interface=gre-to-site1

3. Add routes for the remote LAN

# Router at Site 1
/ip route add dst-address=10.1.202.0/24 gateway=172.16.1.2

# Router at Site 2
/ip route add dst-address=10.1.101.0/24 gateway=172.16.1.1

4. Verify connectivity

/interface gre print
/ping 172.16.1.2
/ping 10.1.202.1 src-address=10.1.101.1

At this point, both LANs reach each other over the tunnel. The GRE interface shows a running flag once traffic passes, though — as covered in the next section — a running flag alone does not confirm the remote end is actually reachable.

Configure Keepalive to Detect Tunnel Failure

Without keepalive, a GRE interface shows as running even when the remote router is completely unreachable. Traffic routed into the tunnel gets blackholed silently — no error, no fallback, just dropped packets.

/interface gre set gre-to-site2 keepalive=10s,10

This sends a keepalive probe every 10 seconds and marks the tunnel down after 10 missed responses. Tune the interval and retry count to match how fast you need failure detection versus how much probe traffic you are willing to generate. Once keepalive is active, pair the tunnel route with a backup route or a routing protocol that reacts to the interface going down, so traffic actually reroutes instead of just being marked as failed.

MTU and Fragmentation

GRE’s 24-byte overhead means a standard 1500-byte Ethernet MTU no longer fits once encapsulated. Left unaddressed, this causes large packets to fragment or drop entirely, while small packets like DNS queries and pings succeed — a classic hard-to-diagnose symptom.

  • Set the tunnel MTU to account for overhead: 
    /interface gre set gre-to-site2 mtu=1476

    1500 minus 24 bytes of GRE overhead leaves 1476. Reduce further if the tunnel also runs over a PPPoE WAN link, which adds its own 8-byte overhead.

  • Enable Path MTU Discovery awareness by not blocking ICMP “fragmentation needed” messages on the firewall — blocking them causes exactly the large-packet-fails-silently symptom this MTU adjustment is meant to prevent.
  • Test with a specific packet size before declaring the tunnel healthy: 
    /ping 172.16.1.2 size=1450 do-not-fragment

Running a Routing Protocol Over GRE

GRE’s biggest advantage over a plain IPsec tunnel is carrying dynamic routing protocols and multicast, which many pure-IPsec setups cannot forward.

/routing ospf instance add name=default-v2 router-id=172.16.1.1
/routing ospf area add instance=default-v2 name=backbone area-id=0.0.0.0
/routing ospf interface-template add interfaces=gre-to-site2 area=backbone

Running OSPF over the GRE link means new LAN subnets on either side get discovered automatically, instead of maintaining static routes by hand every time a site adds a new VLAN.

Encrypt GRE with IPsec

GRE alone sends traffic in plain text. Combine it with IPsec transport mode to encrypt the GRE-encapsulated traffic while keeping GRE’s routing and multicast support:

/ip ipsec profile add name=gre-profile dh-group=modp2048 enc-algorithm=aes-256

/ip ipsec peer add name=gre-peer address=192.168.90.1/32 \
  local-address=192.168.80.1 profile=gre-profile exchange-mode=ike2

/ip ipsec identity add peer=gre-peer secret=YOUR-STRONG-PSK

/ip ipsec proposal add name=gre-proposal enc-algorithms=aes-256-cbc pfs-group=modp2048

/ip ipsec policy add src-address=192.168.80.1/32 dst-address=192.168.90.1/32 \
  protocol=gre tunnel=no sa-src-address=192.168.80.1 sa-dst-address=192.168.90.1 \
  proposal=gre-proposal

Set tunnel=no here — the policy encrypts the GRE traffic in transport mode rather than adding a second layer of tunnel encapsulation, since GRE already provides the tunnel itself. After applying this configuration, confirm encryption is actually happening rather than assuming the policy matched correctly:

/tool profile

Generate traffic across the tunnel and check the profiler output. Seeing encrypting as a significant CPU consumer confirms IPsec is doing real work. If only gre or ethernet shows up as the top consumer, the IPsec policy likely is not matching, and traffic is passing unencrypted.

Real-World Use Cases

  • Branch office connectivity. Connect multiple remote offices into one corporate network over existing internet links, without provisioning dedicated MPLS circuits.
  • BGP peering over the internet. Many transit providers and internet exchanges offer GRE-based BGP peering sessions, letting you exchange routes over a stable tunnel address instead of a public IP that might change.
  • Cloud hybrid connectivity. Build a GRE tunnel to a cloud provider’s edge router to extend on-premises routing into a VPC, without a full site-to-site VPN appliance.
  • Multicast transport. GRE forwards multicast traffic across networks that would otherwise drop it, useful for video distribution or clustered application traffic between sites.
  • Lab and WAN simulation. Build GRE tunnels between lab routers to simulate multi-site WAN topologies for training or protocol testing, without needing physical WAN circuits.
  • ISP traffic segregation. Providers use GRE internally to separate customer traffic streams across a shared core network.

Firewall Rules for GRE

GRE traffic needs explicit firewall handling, since it runs as IP protocol 47 rather than TCP or UDP:

/ip firewall filter
add chain=input protocol=gre action=accept comment="Allow GRE tunnel traffic"
add chain=forward protocol=gre action=accept comment="Allow GRE forwarding"
  • Place GRE accept rules before any general drop rule in the chain — a catch-all drop placed earlier silently blocks the tunnel with no obvious error.
  • Restrict by source address once the tunnel is stable, rather than accepting GRE from any source: 
    add chain=input protocol=gre src-address=192.168.90.1 action=accept
  • Check NAT devices between the endpoints. GRE has no port number, which breaks some NAT implementations that expect TCP or UDP. Where possible, run GRE endpoints on public IPs directly rather than behind NAT.

Troubleshooting GRE Tunnels

Tunnel interface shows running, but no traffic passes

  • Cause: GRE has no built-in liveness check without keepalive configured — running only means the interface is administratively up, not that the remote end responds.
  • Fix: Enable keepalive (see Step 4 above) and confirm both routers show the same tunnel state after enabling it.

Small packets work, large transfers fail or hang

  • Cause: MTU mismatch. The 24-byte GRE overhead pushes packets past the path MTU, and fragmentation either fails or gets blocked.
  • Fix: Set the tunnel MTU explicitly (Step: MTU and Fragmentation) and confirm ICMP fragmentation-needed messages are not blocked in the firewall.

Tunnel does not come up at all

  • Cause 1: Incorrect local or remote address on one end — GRE requires the addresses to match exactly in both directions.
  • Cause 2: A firewall or upstream NAT device is blocking IP protocol 47.
  • Fix: Confirm addressing with /interface gre print detail on both routers, and confirm GRE is explicitly allowed in the firewall chain covered above.

Tunnel works, but OSPF or BGP neighbors never form

  • Cause: Routing protocol traffic (multicast for OSPF, or the BGP TCP session) is being dropped by a firewall rule that only accounts for the GRE protocol itself, not the traffic riding inside it.
  • Fix: Remember that traffic inside the GRE tunnel needs its own firewall consideration on the forward chain, separate from the GRE protocol-47 rule that only covers the outer encapsulation.

IPsec-protected GRE traffic appears unencrypted

  • Cause: The IPsec policy is not matching the GRE traffic, often due to a source/destination address mismatch between the policy and the actual tunnel endpoints.
  • Fix: Run /tool profile under load and confirm encrypting shows as a real CPU consumer, not just gre. Re-check the policy’s protocol=gre match and address fields if encryption is not happening.

Quick-Reference Configuration Cheat Sheet

# Create the GRE interface
/interface gre add name=gre-to-remote local-address=WAN_IP remote-address=REMOTE_WAN_IP

# Assign tunnel addressing
/ip address add address=172.16.1.1/30 interface=gre-to-remote

# Route the remote LAN through the tunnel
/ip route add dst-address=REMOTE_LAN/24 gateway=172.16.1.2

# Enable keepalive for failure detection
/interface gre set gre-to-remote keepalive=10s,10

# Set MTU to account for GRE overhead
/interface gre set gre-to-remote mtu=1476

# Allow GRE through the firewall
/ip firewall filter add chain=input protocol=gre action=accept
/ip firewall filter add chain=forward protocol=gre action=accept

# Test the tunnel
/ping 172.16.1.2 size=1450 do-not-fragment

Deployment Checklist

  • Confirm both endpoints have static, reachable public IP addresses
  • Create GRE interfaces with matching local/remote addresses on each side
  • Assign a /30 tunnel subnet between the two GRE interfaces
  • Add routes for each remote LAN through the tunnel gateway
  • Enable keepalive so a dead tunnel is detected, not silently blackholed
  • Set tunnel MTU to 1476 or lower, adjusted for any additional WAN overhead
  • Allow IP protocol 47 explicitly in the firewall, on both input and forward chains
  • Add IPsec transport-mode encryption if the traffic needs confidentiality
  • Confirm with /tool profile that IPsec is actually encrypting, not just present in the configuration
  • Test with a packet size close to the tunnel MTU, not just a small default ping

Conclusion

GRE earns its place whenever a tunnel needs to carry more than plain IP traffic — routing protocols, multicast, or a stable BGP peering address. Configuration on RouterOS is genuinely simple: two interfaces, a tunnel subnet, and a route. The real work is in what most guides skip — keepalive for failure detection, MTU sized for the 24-byte overhead, and IPsec layered on top when encryption matters. Get those three right, and the tunnel that looked simple on day one stays stable in production.

Check our list of MikroTik guides

Similar Posts

Leave a Reply

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