Configure and test a GRE tunnel on Sophos Firewall

A GRE tunnel connects two IP endpoints and carries routed traffic inside it. On Sophos Firewall, it is created in the Device Console with system gre. This is suitable, for example, for a provider on-ramp, a simple overlay path, or a transport that explicitly requires GRE.

Quick answer

For a safe setup, first document the outer WAN endpoints, the inner tunnel IPs, and the remote networks. Then:

Verify underlay reachability between both WAN endpoints and IP protocol 47.
Create the GRE tunnel symmetrically on both firewalls with system gre tunnel add.
Use system gre tunnel show to verify names, endpoints, tunnel IPs, and status.
Assign the remote networks to the tunnel with system gre route add.
Create narrow, logged firewall rules between LAN and VPN.
Test GRE on the WAN path, the inner route, Rule ID, application traffic, and return path separately.

⚠️ GRE itself provides no encryption or authentication. Over an untrusted network, use GRE only when unencrypted transport is explicitly accepted in the security design. If confidentiality or peer authentication is required, a site-to-site IPsec VPN is generally a better fit.

Distinguish GRE endpoints, tunnel IPs, and routes

A GRE design consists of several layers:

Local gateway: the local WAN interface of Sophos Firewall, for example Port2.
Remote gateway: the outer IPv4 address of the peer.
Local IP and Remote IP: the inner point-to-point addresses of the GRE tunnel.
GRE route: assigns a remote host or destination network to the tunnel.
Firewall rule: allows the specific data flow between zones and networks.
Return path: returns response packets through the symmetrical tunnel.

GRE over IPv4 uses IP protocol 47. This is neither TCP nor UDP and must not be confused with port 47. An upstream router, provider filter, or cloud security list must therefore be able to carry the IP protocol between both outer endpoints.

A visible tunnel status of Enabled confirms the saved and enabled GRE configuration. It does not yet prove that the peer responds, the route is correct, or an application works.

When GRE fits and when IPsec is more appropriate

GRE is lightweight and carries routed traffic between two defined endpoints. It fits when a provider or platform requires GRE, when only encapsulation is needed, or when a trusted underlay path is already protected separately.

GRE is not a substitute for encrypted site connectivity. For ordinary connections over the public internet, route-based IPsec is usually the better starting point. Combining GRE and IPsec requires a separate design tested on both devices; this basic procedure does not create an unverified GRE-over-IPsec path.

This article covers a static IPv4 point-to-point tunnel. Multicast, PIM-SM, BGP over GRE, and provider-specific anycast tunnels are possible extensions, but they are planned only after the basic unicast path works.

Plan the example topology

The example connects two Sophos Firewalls:

Site A WAN: Port2 with 192.0.2.10
Site A LAN: 10.10.10.0/24
Site A tunnel IP: 10.255.255.1
Site B WAN: Port2 with 198.51.100.20
Site B LAN: 10.20.20.0/24
Site B test server: 10.20.20.10
Site B tunnel IP: 10.255.255.2
Tunnel network: 10.255.255.0/30
Test service: HTTPS or TCP 443

192.0.2.0/24 and 198.51.100.0/24 are documentation networks and are not used in production. Replace both WAN addresses, interfaces, tunnel IPs, LAN networks, and the test server together with the real values. The tunnel IPs must form a dedicated point-to-point network planned identically on both sides and must not overlap existing networks.

The example uses the tunnel names gre_branch at site A and gre_hq at site B. The names are freely selectable, but the current SFOS 22 API limits them to 15 characters.

Before making changes, prepare a configuration backup, a maintenance window, and independent management access for recovery. Also record existing static and SD-WAN routes, NAT rules, firewall rules, and overlapping networks.

Verify prerequisites on the outer path

Both WAN endpoints must be able to reach each other over the underlay. The basic design uses static IPv4 addresses on both sides. If the local WAN address is assigned through PPPoE or DHCP, do not continue with this procedure: Older official Sophos GRE instructions exclude dynamic local WAN interfaces, while the current SFOS 22 API only documents DDNS for the Remote Gateway. Support must therefore be clarified for the specific build and connection.

Verify the following before configuring the tunnel:

The remote WAN address is routed through the expected WAN gateway.
Upstream routers, providers, and cloud ACLs permit IP protocol 47 between both endpoints.
There is no CGNAT or NAT design whose GRE behaviour has not been clarified.
The inner tunnel IPs and LAN networks do not overlap locally or remotely.
The peer uses the same outer and inner values in reverse.
A return path to both LAN networks is planned.

A ping to the public peer can support the underlay test but does not prove GRE support. Likewise, allowing TCP or UDP port 47 does not help because GRE is not a port-based transport protocol.

Create the GRE tunnel on both firewalls

Configuration takes place in CLI menu 4. Device Console. The current Sophos help page contains incorrectly rendered syntax fragments. Before making a change on the target build, use Tab or ? to confirm that the following parameters are offered.

Configure site A

On firewall A, enter the local WAN port Port2, outer peer 198.51.100.20, and the inner tunnel pair:

system gre tunnel add name gre_branch local-gw Port2 remote-gw 198.51.100.20 local-ip 10.255.255.1 remote-ip 10.255.255.2

Then perform this read-only check:

system gre tunnel show

The entry must show gre_branch, Port2, the remote WAN address, and both tunnel IPs correctly. Do not hide a typo by creating a second, similarly named configuration.

Configure site B symmetrically

On firewall B, reverse the local and remote values:

system gre tunnel add name gre_hq local-gw Port2 remote-gw 192.0.2.10 local-ip 10.255.255.2 remote-ip 10.255.255.1

Again, perform the read-only check:

system gre tunnel show

At this point, Enabled is only an intermediate check. Validation is complete only when a real LAN-to-LAN data flow works.

Route remote networks through GRE

For the simple fixed path, add a GRE route on each firewall. Site A sends site B’s LAN through gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

Site B receives the symmetrical return path:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Then read the configured assignments on both devices:

system gre route show

The route must not compete with an equally long or more specific static, SD-WAN, VPN, or directly connected path. Do not change global Route Precedence on suspicion. First prove the route that actually matched and the packet path.

Custom Gateway and SD-WAN as an alternative

Some provider designs use a Custom Gateway on the GRE path instead of the simple GRE route and select it in an SD-WAN route. This fits when source, service, failover, or a defined gateway status should influence the routing decision.

The remote tunnel IP is the next hop. Health Check, Zone, and Probe Target must match the specific provider design; monitoring disabled in one vendor guide is not a universal standard. Create and verify a Custom Gateway on Sophos Firewall explains how object, probe, and real traffic test fit together. Path selection is covered in Configure an SD-WAN route on Sophos Firewall.

Do not enable a GRE route and an SD-WAN route for the same networks without control. Before switching, document which mechanism should win and how to return to the previous path.

Create firewall rules without unnecessary NAT

The GRE tunnel and its route do not yet allow application traffic. An HTTPS connection initiated from site A requires a narrow, logged rule on both firewalls.

On firewall A:

Source zone: LAN
Source network: 10.10.10.0/24
Destination zone: VPN
Destination network: 10.20.20.10
Services: HTTPS
Action: Accept
Log firewall traffic: enabled

On firewall B, allow incoming tunnel traffic to the test server:

Source zone: VPN
Source network: 10.10.10.0/24
Destination zone: LAN
Destination network: 10.20.20.10
Services: HTTPS
Action: Accept
Log firewall traffic: enabled

These two rules cover the connection initiated from site A and its stateful return traffic. If hosts at site B may initiate new connections to site A, also create the symmetrical rule pair from LAN to VPN on firewall B and from VPN to LAN on firewall A, using only the networks and services actually required. A broad Any rule is not needed for validation.

For normal site connectivity, retain the original source IP. Do not enable MASQ as an apparent routing fix. If the return path is missing, correct the route at the peer. Create and safely verify Sophos Firewall rules explains the general rule design.

Validate the tunnel and application traffic together

Follow the packet path and distinguish configuration from actual function:

Run system gre tunnel show on both firewalls and compare endpoints and tunnel IPs.
Use system gre route show to verify the corresponding remote LAN and the correct tunnel name.
From a client in 10.10.10.0/24, start a new HTTPS connection to 10.20.20.10.
In Log viewer on both firewalls, verify Source, Destination, Service, Firewall Rule ID, NAT Rule ID, and Zone.
Under Diagnostics > Packet capture at site A, filter the outer GRE path:
```
host 198.51.100.20 and ip proto 47
```
Filter the inner test flow separately:
```
host 10.20.20.10 and tcp port 443
```
Compare ingress and egress on both firewalls and verify the real source IP on the destination server.
Run a return test only with a service allowed for that purpose.

The outer capture shows encapsulation between the WAN endpoints. The inner capture and Rule ID show whether the payload packet follows the expected rule and route. Only the successful application confirms the complete path. The combined procedure is covered in more detail in Test firewall rules and Use packet capture.

Troubleshoot by symptom

No GRE packet leaves the WAN interface

Check Remote Gateway and local local-gw in the tunnel.
Check the underlay route to the remote WAN address and the selected WAN gateway.
Make sure the test flow actually matches the GRE route or intended SD-WAN route.
Compare names and assignments with system gre tunnel show and system gre route show.
Do not create a TCP or UDP port rule as a replacement for IP protocol 47.

GRE leaves site A but does not reach site B

Check providers, upstream routers, cloud ACLs, and possible NAT paths for IP protocol 47.
Capture simultaneously at site B with the outer WAN filter.
Compare outer source and destination addresses with the peer configuration.
With a dynamic WAN, CGNAT, or unresolved NAT design, stop rather than hiding the problem with broad rules.

GRE is visible at both WAN sides, but the inner traffic is missing

Local IP and Remote IP must be reversed symmetrically on both firewalls.
Compare GRE route, destination network, and tunnel name character by character.
Check the firewall rule and expected Rule ID on both sides.
Rule out overlapping networks, NAT, and a missing return path.
Do not treat Enabled as proof of the inner route or application.

Only one direction works

Check the GRE route for the return network at site B.
Determine whether site B must initiate new connections and therefore needs its own firewall rule.
Check the default gateway, local host firewall, and real source IP at the destination server.
Compare asymmetric SD-WAN or static routes on both sides.

Small packets work, but large connections stall

GRE adds an outer IP header and a GRE header. This reduces the usable packet size compared with the underlay. Do not adopt a fixed MTU or MSS value without verification: First measure the underlay MTU, Path MTU Discovery, fragmentation, and the affected application. Check MTU and MSS for VPN issues explains the controlled procedure.

Test HA and operations cautiously

The current public Sophos documentation does not promise seamless HA failover or synchronized tunnel state for GRE. Therefore, perform a controlled role change only during a maintenance window with independent management access.

After the change, verify system gre tunnel show, system gre route show, the outer GRE capture, a new client connection, Rule ID, and return path again. An existing TCP connection is not proof of continuity.

For operations, document the owner, both WAN endpoints, tunnel IPs, tunnel names, remote networks, routing mechanism, firewall rules, expected MTU limit, and last real traffic test. After changes to WAN, provider, NAT, SD-WAN, Route Precedence, or peer, validate the complete path again.

Roll back safely

Coordinate the rollback on both firewalls:

Stop test traffic and record the latest state with system gre tunnel show and system gre route show.
Disable new firewall rules and any SD-WAN route created for the test.
If used, remove the Custom Gateway from the path only after checking Object usage.

At site A, remove the specific GRE route:

system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch

At site B, remove the return route:

system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Use system gre route show to verify that only the intended entries disappeared.
Then delete the tunnel at site A by its exact name:
```
system gre tunnel del name gre_branch
```
At site B, delete only the tunnel configured there:
```
system gre tunnel del name gre_hq
```
Finish with system gre tunnel show and a test of the previous routing path.

Do not use del All. If syntax or an object name is unclear on the target build, check with Tab or ? before deleting and do not guess.

Frequently asked questions

Is a GRE tunnel the same as a VPN?

GRE creates a logical tunnel and is assigned to the VPN zone on SFOS, but it provides no encryption or peer authentication itself. Confidential traffic over the internet normally uses IPsec or another explicitly protected transport.

Why is the tunnel Enabled even though no traffic works?

Enabled confirms the active GRE configuration. It proves neither peer reachability nor GRE routes, firewall rules, MTU, NAT, or the return path. Therefore, test the outer GRE path and inner application traffic separately.

Can GRE be used with a dynamic WAN address?

This procedure assumes static local WAN addresses. The current SFOS 22 API documents DDNS for the Remote Gateway, but older official Sophos instructions exclude GRE on local PPPoE and DHCP WAN interfaces. Do not deploy the design in production without current confirmation for the specific build and connection.