FortiGate-to-FortiGate GRE Tunnel Deployment Guide

By Manny Fernandez

June 27, 2026

FortiGate-to-FortiGate GRE Tunnel Deployment Guide

Overview

A FortiGate can build a strictly GRE tunnel to another FortiGate with no IPsec involved. FortiOS implements Generic Routing Encapsulation per RFC 2784 (with RFC 1701 heritage) as a native, routable tunnel interface configured under config system gre-tunnel. The result is a Layer 3 point-to-point virtual interface that encapsulates passenger traffic in IP protocol 47.

This guide walks through a clean two-FortiGate GRE build: the tunnel definition, the transport (underlay) reachability, tunnel interface addressing, routing across the overlay, and the firewall policies that make it actually pass traffic. It closes with keepalives, MTU/MSS handling, verification, and troubleshooting.

Important security note. GRE provides no confidentiality, no integrity, and no authentication. Anything you send across a bare GRE tunnel traverses the underlay in cleartext. Use bare GRE only across trusted transport (private WAN, MPLS, lab, or a path you already trust). If the underlay is the public internet, wrap GRE in IPsec (GRE-over-IPsec) instead. This guide intentionally covers the strictly-GRE case as requested.

When to use bare GRE

GRE on its own earns its place in a few specific scenarios:

– Multicast or non-IP passenger protocols across an IP core – Plain IPsec tunnel-mode does not natively carry multicast; GRE does, which is why GRE-over-IPsec exists. Bare GRE alone carries multicast where the path is already trusted.
– Routing protocol adjacencies over a simple point-to-point overlay – OSPF, BGP, or RIP can ride the GRE interface as if it were a normal point-to-point link.
– Connecting two sites across a private/MPLS underlay where the provider already isolates traffic and encryption is not required.
– Lab and interoperability testing, including GRE peering with non-Fortinet routers (Cisco IOS, Linux, etc.).

If the data crosses an untrusted network, do not use bare GRE. Move to GRE-over-IPsec.

Reference topology

This guide uses two FortiGates connected across a routed transport network. The transport could be the internet (lab only), an MPLS handoff, or a private WAN.

Element	FortiGate A (HQ)	FortiGate B (Branch)
Underlay (WAN) interface	Server (VLAN)	port1
Underlay IP (transport)	10.1.106.1	10.1.106.180
GRE tunnel interface name	gre-to-branch	gre-to-DC
GRE local gateway	10.1.106.1	10.1.106.2
GRE remote gateway	10.1.106.180	10.1.106.1
Tunnel interface IP (overlay)	198.19.249.1/32	198.19.240.2/32
Tunnel remote IP (overlay peer)	198.19.240.2	198.19.240.1
LAN behind device	198.19.250.1/32 (LB)	198.19.250.2/32 (LB)

The overlay /32 plus remote-IP model is the FortiOS idiom for GRE: you assign the tunnel interface a host address and explicitly point it at the peer’s tunnel address. A /30 also works; the /32 + remote approach is cleaner and avoids wasted addressing.

Prerequisites

Before configuring the tunnel, confirm:

1. Underlay reachability – FortiGate A must be able to reach FortiGate B’s transport IP and vice versa. Test with `execute ping`. GRE rides on top of this; if the underlay is down, the tunnel never comes up.
2. IP protocol 47 is permitted end to end – GRE is its own IP protocol (47), not TCP or UDP. Any intermediate firewall, ISP filter, or upstream policy must allow protocol 47 in both directions. This is the single most common reason a GRE tunnel silently fails.
3. No overlapping LAN subnets – between the two sites (or you will need NAT, which is out of scope here).
4. Administrative access – to both FortiGates (CLI strongly recommended for GRE; the GUI exposes only part of the configuration).

Step 1 — Confirm underlay reachability

On FortiGate A:

execute ping 10.1.106.180

On FortiGate B:

execute ping 10.1.106.1

Both must succeed before continuing. If they do not, fix routing and policy on the underlay first. Nothing below will work until the transport path is healthy.

Step 2 — Create the GRE tunnel interface

GRE tunnels are defined under config system gre-tunnel. This creates the logical tunnel and binds it to a local underlay interface and the remote peer’s transport address.

FortiGate A (HQ):

config system gre-tunnel
edit "gre-to-branch"
set interface "Server"
set local-gw 10.1.106.1
set remote-gw 10.1.106.180
next
end

FortiGate B (Branch):

config system gre-tunnel
edit "gre-to-DC"
set interface "port1"
set local-gw 10.1.106.180
set remote-gw 10.1.106.1
next
end

Field meanings:

– interface is the underlay interface that sources the GRE packets (the egress WAN port).
– local-gw is this FortiGate’s own transport IP used as the GRE source.
– remote-gw is the peer FortiGate’s transport IP, the GRE destination.

At this point the tunnel object exists and a system interface with the same name (gre-to-Branch / gre-to-DC) is automatically created, but it has no IP addressing yet.

Step 3 — Address the tunnel interface

The GRE interface needs an overlay IP and an explicit pointer to the peer’s overlay IP. This is done under config system interface on the auto-created tunnel interface.

FortiGate A (HQ):

config system interface
edit "gre-to-Branch"
set ip 198.19.240.1 255.255.255.255
set remote-ip 198.19.240.2 255.255.255.255
set allowaccess ping
next
end

FortiGate B (Branch):

config system interface
edit "gre-to-DC"
set ip 198.19.240.2 255.255.255.255
set remote-ip 198.19.240.1 255.255.255.255
set allowaccess ping
next
end

Notes:

– ip is this side’s tunnel (overlay) address as a /32.
– remote-ip tells FortiOS the peer’s tunnel address so it can resolve the point-to-point next hop. On older FortiOS, the mask field on remote-ip is required; supply 255.255.255.255.
– allowaccess ping lets you ping the tunnel interface IP for verification. Keep it minimal; do not enable management protocols on the tunnel unless you need them.

Step 4 — Route traffic across the tunnel

The tunnel is now addressable, but the FortiGate has no reason to send LAN traffic through it. Add static routes for the remote LAN pointing at the GRE interface. Because it is a point-to-point interface, you route to the interface itself (a gateway is not strictly required, though specifying the peer overlay IP is fine).

FortiGate A (HQ) — reach Branch LAN 198.19.250.2/32:

config router static
edit 0
set dst 198.19.250.2 255.255.255.255
set device "gre-to-Branch"
next
end

FortiGate B (Branch) — reach HQ LAN 10.10.0.0/24:

config router static
edit 0
set dst 198.19.250.1 255.255.255.255
set device "gre-to-DC"
next
end

If you prefer a dynamic routing protocol over the tunnel, you can instead form an OSPF or BGP adjacency on the 198.19.240/30-style overlay. Static routing is shown here for clarity.

Step 5 — Firewall policies for tunneled traffic

GRE tunnel traffic must be permitted by policy, in both directions, treating the GRE interface as the tunnel zone. You need policies allowing LAN-to-tunnel and tunnel-to-LAN.

FortiGate A (HQ):

config firewall policy
edit 0
set name "LAN-to-GRE-Branch"
set srcintf "port2"
set dstintf "gre-to-Branch"
set srcaddr "HQ-LAN"
set dstaddr "Branch-LAN"
set action accept
set schedule "always"
set service "ALL"
next
edit 0
set name "GRE-B-to-LAN"
set srcintf "gre-to-Branch"
set dstintf "port2"
set srcaddr "Branch-LAN"
set dstaddr "HQ-LAN"
set action accept
set schedule "always"
set service "ALL"
next
end

FortiGate B (Branch):

config firewall policy
edit 0
set name "LAN-to-GRE-DC"
set srcintf "port2"
set dstintf "gre-to-DC"
set srcaddr "Branch-LAN"
set dstaddr "HQ-LAN"
set action accept
set schedule "always"
set service "ALL"
next
edit 0
set name "GRE-A-to-LAN"
set srcintf "gre-to-DC"
set dstintf "port2"
set srcaddr "HQ-LAN"
set dstaddr "Branch-LAN"
set action accept
set schedule "always"
set service "ALL"
next
end

Define HQ-LAN (198.19.250.1/32) and Branch-LAN (198.19.250.2/32) as firewall address objects on the respective devices first. Do not enable NAT on these policies for site-to-site routed traffic; you want the original source addresses preserved across the tunnel.

Disclaimer: Service ALL is shown for brevity. In production, scope policies to the services and source/destination objects actually required, and apply security profiles per your standards rather than permitting all traffic between sites.

Step 6 — (Optional) GRE keepalives

By default a GRE tunnel interface can appear “up” even when the peer is unreachable, because GRE is stateless. Keepalives let the FortiGate detect a dead peer and bring the interface down so routing can react. Keepalives are configured on the tunnel object.

Both FortiGates (adjust names):

config system gre-tunnel
edit "gre-to-Branch"
set keepalive-interval 5
set keepalive-failtimes 4
next
end

– keepalive-interval is seconds between keepalive probes.
– keepalive-failtimes is the number of consecutive missed probes before the tunnel is declared down.

With the values above, the tunnel is marked down after roughly 20 seconds of lost keepalives. Both ends should run keepalives for symmetric detection.

Step 7 — MTU and MSS handling

GRE adds 24 bytes of overhead (20-byte outer IP header + 4-byte GRE header). On a standard 1500-byte underlay, the effective tunnel payload MTU is about 1476 bytes. Without adjustment, large TCP flows can blackhole when DF is set and PMTUD is filtered.

Two common mitigations:

1. TCP MSS clamping on the tunnel policies (recommended, robust):

config firewall policy
edit <policy-id-for-tunnel>
set tcp-mss-sender 1436
set tcp-mss-receiver 1436
next
end

1436 = 1476 tunnel MTU minus 40 bytes of TCP/IP header. Apply to the policies that send traffic into the tunnel on both FortiGates.

2. Set the tunnel interface MTU explicitly (if you need to override):

config system interface
edit "gre-to-Branch"
set mtu-override enable
set mtu 1476
next
end

MSS clamping is generally the more reliable fix because it works regardless of PMTUD behavior on intermediate hops.

Verification

Check the tunnel interface state:

get system interface physical | grep -A2 gre-to-branch
diagnose netlink interface list gre-to-branch

Ping the peer’s tunnel (overlay) IP from FortiGate A:

execute ping 198.19.250.255.2

If this succeeds, GRE encapsulation and the overlay are working.

Ping across to the remote LAN, sourced from the local LAN interface:

execute ping-options source 198.19.250.2
execute ping 198.19.250.1

Confirm the route resolves to the tunnel:

get router info routing-table static

You should see 198.19.250.2/32 via the gre-to-Branch interface.

Watch GRE packets on the underlay (sniffer):

diagnose sniffer packet port1 'proto 47' 4

Protocol 47 packets flowing in both directions confirm GRE is on the wire.

Troubleshooting

Symptom	Likely cause	Action
Tunnel interface never comes up	Underlay unreachable, or local-gw/remote-gw reversed	Verify execute ping to peer transport IP; recheck local-gw and remote-gw
Underlay pings work, overlay ping fails	IP protocol 47 blocked by an upstream/ISP filter	Sniff proto 47 on both ends; confirm protocol 47 permitted end to end
Overlay ping works, LAN-to-LAN fails	Missing route or missing firewall policy	Check static route device and the tunnel policies in both directions
Large transfers stall, small pings fine	MTU/MSS, DF plus filtered PMTUD	Apply MSS clamping (1436) on tunnel policies
Tunnel shows up but peer is dead	No keepalives; GRE is stateless	Enable keepalive-interval / keepalive-failtimes on both ends
Asymmetric or no return traffic	remote-ip not set or wrong on tunnel interface	Confirm set remote-ip points at the peer’s /32 tunnel address
Traffic leaves unencrypted (expected)	Bare GRE has no encryption by design	If confidentiality is required, migrate to GRE-over-IPsec

Appendix A — Bare GRE versus GRE-over-IPsec

Attribute	Bare GRE (this guide)	GRE-over-IPsec
Encryption	None	IPsec ESP encryption
Integrity / authentication	None	IPsec authentication
Carries multicast / routing protocols	Yes	Yes
Suitable over public internet	No	Yes
Suitable over trusted/private WAN	Yes	Yes (defense in depth)
Overhead	~24 bytes	~24 bytes GRE + IPsec overhead
Config complexity	Lower	Higher

If you ever need to add encryption later, the migration path is to build a phase1/phase2 IPsec tunnel between the same transport endpoints and bind the GRE tunnel inside it, rather than rebuilding the overlay from scratch.

FortiGate-to-FortiGate GRE Tunnel Deployment Guide

Overview

When to use bare GRE

Reference topology

Prerequisites

Step 1 — Confirm underlay reachability

Step 2 — Create the GRE tunnel interface

Step 3 — Address the tunnel interface

Step 4 — Route traffic across the tunnel

Step 5 — Firewall policies for tunneled traffic

Step 6 — (Optional) GRE keepalives

Step 7 — MTU and MSS handling

2. Set the tunnel interface MTU explicitly (if you need to override):

Verification

Troubleshooting

Appendix A — Bare GRE versus GRE-over-IPsec

Recent posts