Configure a Sophos Firewall IP tunnel with 6in4, 6to4, 6rd, or 4in6

Under Network > IP tunnels, Sophos Firewall creates tunnels that encapsulate one network protocol in another. This allows IPv6 to cross an IPv4 underlay, or IPv4 to cross an IPv6 underlay. SFOS provides 6in4, 6to4, 6rd, and 4in6 for these scenarios.

This feature isn’t the GRE tunnel from the Device Console, and it isn’t an IPsec VPN. An IP tunnel encapsulates packets, but doesn’t automatically encrypt or authenticate them.

⚠️ Only use an IP tunnel over an untrusted underlay when the security design explicitly accepts the lack of confidentiality and peer authentication. For protected site connectivity, site-to-site IPsec is usually the better starting point.

Which tunnel type fits?

The four types don’t solve the same problem:

• 6in4 connects two IPv6 networks across an IPv4 backbone. You set the local and remote IPv4 endpoints manually. Sophos recommends this type for point-to-point connections.
• 6to4 carries IPv6 over IPv4 and is intended for point-to-multipoint designs. You set the local IPv4 source manually, while the destination address can be obtained automatically.
• 6rd extends 6to4 with a prefix supplied by the provider. It only fits when the ISP supplies the required 6rd values.
• 4in6 connects two IPv4 networks across an IPv6 backbone. The outer local and remote tunnel endpoints are IPv6 addresses, and the type is intended for point-to-point connections.

For one controlled link with fixed endpoints, 6in4 or 4in6 is easier to reason about. Don’t choose 6to4 or 6rd merely because SFOS can create a route automatically. The addressing and provider design must match that exact mechanism.

IPv6 support on Sophos Firewall summarizes the SFOS IPv6 boundaries. A GRE tunnel, in contrast, carries routed IP traffic through a separate Device Console workflow and isn’t interchangeable with these four WebAdmin types.

Plan the example and prerequisites

The example uses a static 6in4 tunnel between two sites:

• Display name: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Local IPv4 WAN address: 192.0.2.10
• Remote IPv4 endpoint: 198.51.100.20
• Local IPv6 network: 2001:db8:100::/64
• Remote IPv6 network: 2001:db8:200::/64
• Test server: 2001:db8:200::20
• Tunnel interface zone: VPN in this example

192.0.2.0/24, 198.51.100.0/24, and 2001:db8::/32 are documentation ranges. Replace them, along with the names, zone, and prefixes, with the real values. The VPN zone is a comprehensible example choice, not a product requirement. The important point is that the zone model, firewall rules, and Device Access match the actual architecture.

Both outer endpoints must be reachable across the underlay before the tunnel is created. Both sides need a mirrored tunnel, unique inner networks, a return path, and a firewall rule for the real application traffic. Overlapping prefixes, a missing provider value for 6rd, or an unknown peer configuration are stop conditions.

A backup, a maintenance window, and independent management access are also part of the recovery plan. Don’t build the tunnel as an experiment on the only production connection.

Create the IP tunnel in WebAdmin

Under Network > IP tunnels > Add, first set the identity and tunnel type, then the endpoints and advanced IP values.

Distinguish Name from Hardware name

The regular Name can contain up to 58 characters and can be changed later. It should identify the purpose and peer, such as HQ-IPv6-via-IPv4.

The Hardware name is technical and can’t be changed after saving. It can contain up to ten characters and only A-Z, a-z, 0-9, and _. SFOS also blocks many system names and substrings, including gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN, and Halink. The neutral example v6hq01 avoids those conflicts.

An incorrect Hardware name isn’t renamed later. Its dependencies must be documented and the tunnel recreated in a controlled way. Check this value especially carefully before selecting Save.

Set the tunnel type, zone, and endpoints

Select 6in4 for this example. Set the intended security zone under Zone. Enter 192.0.2.10 under Local endpoint and 198.51.100.20 under Remote endpoint.

The address family depends on the type. For 6in4, 6to4, and 6rd, the local outer endpoint is IPv4; 6in4 also has a fixed remote IPv4 endpoint. For 4in6, the local and remote outer endpoints are IPv6 addresses. Don’t enter an inner destination route in an endpoint field.

In the advanced settings, TTL affects how long encapsulated packets can live across the underlay. TOS assigns a type-of-service value to the outer IP packet for prioritization and routing behavior. The current help doesn’t specify universal best values. Keep both fields at the documented starting value unless a measured routing or QoS problem justifies a change.

After Save, SFOS confirms the creation and opens the route dialog. For 6to4 and 6rd, the firewall also creates a static IPv6 unicast route automatically. Important: Closing this window or selecting Cancel doesn’t remove the tunnel or any routes that were created automatically.

Add routes and firewall rules

A saved tunnel isn’t yet a working data path. For 6in4, add a static IPv6 route for the remote prefix 2001:db8:200::/64 through the new tunnel interface. The peer needs the mirrored return path to 2001:db8:100::/64.

For 4in6, the inner route leads to an IPv4 destination network. For 6to4 and 6rd, read the automatically created IPv6 route and compare it with the provider design before adding more routes. Cancel in the first route dialog isn’t a rollback.

Add further routes under Routing > Static routes. Static routes on Sophos Firewall explains how the destination prefix, interface, distance, route decision, and real traffic test fit together.

Then create a narrow, logged firewall rule between the participating zones using the real source, destination, and service values. For a normal site connection, retain the original source address; don’t enable MASQ as a substitute for a missing return path. See Configure Sophos Firewall rules securely for the rule workflow.

Validate the tunnel and application traffic

The validation separates saved configuration, outer encapsulation, and the inner application:

1. Under Network > IP tunnels, compare Name, Hardware name, type, Zone, and endpoints with the peer.
2. Under Routing > Static routes, verify that the remote inner prefix points to the expected tunnel interface.
3. Run Route Lookup for the inner test server and confirm the expected interface.
4. From the local test client, start a new connection to 2001:db8:200::20 using an explicitly allowed service.
5. In Log Viewer, check Source, Destination, Service, Action, and Firewall Rule ID.
6. With Packet Capture, observe the outer endpoints first and then the inner test address.
7. At the peer, verify ingress, decapsulation, the return route, and the actual source address.
8. Repeat the test in the opposite direction only with a rule intended for that direction.

A green or present tunnel entry proves neither the route nor the peer. An automatically created route likewise doesn’t prove that the provider, upstream devices, and firewall rules actually carry the encapsulation. Packet Capture on Sophos Firewall explains the controlled capture process.

Troubleshoot by symptom

The tunnel can’t be saved

Check Name and Hardware name separately. Hardware name can be at most ten characters, must use only permitted characters, and must not contain a blocked system term. Then confirm that the tunnel type and the address family of the local and remote endpoints match.

A different display name doesn’t fix an invalid Hardware name. If another interface already uses the field value, plan one unique technical name rather than repeatedly trying random suffixes.

The tunnel exists, but there is no route to the destination network

For 6in4 and 4in6, explicitly add the required static route. For 6to4 and 6rd, verify that SFOS created the expected IPv6 unicast route and that its prefix matches the design. A window previously closed with Cancel doesn’t delete the automatically saved configuration.

Route Lookup and the routing table are the next evidence. Don’t change global Route Precedence on suspicion, and don’t add a competing blackhole or dummy route as a test aid.

Outer packets are visible, but inner traffic is missing

The peer type, endpoint addresses, inner prefix, or return route are often mismatched. Compare both configurations as mirrors. Then verify the firewall rule, the expected Firewall Rule ID, and a capture of the inner source and destination address.

Working encapsulation doesn’t prove that the application traffic is allowed. Conversely, a missing Rule ID can mean that the inner packet was never decapsulated or was handled by a different route.

Small packets work, but applications stall

The additional outer IP encapsulation reduces the usable packet size compared with the underlay. Instead of copying an unrelated MTU value, measure path MTU, fragmentation, and the affected application. The controlled workflow in Check MTU and MSS for tunnel issues also applies to this packet-size analysis, but don’t copy fixed IPsec values to an IP tunnel.

HA, changes, and rollback

The two SFOS 22 help pages don’t promise uninterrupted HA state for these IP tunnels. After a planned role switch, recheck the tunnel entry, Route Lookup, outer encapsulation, Firewall Rule ID, and a new application session. An existing connection isn’t proof of continuity.

Before making a change, document the Name, immutable Hardware name, type, Zone, endpoints, automatically and manually created routes, rules, and last real traffic test. This separates a configuration change from a data-path change.

For rollback, stop test traffic first. Disable dependent firewall rules and manual routes in a controlled way, or restore their confirmed previous state. Explicitly check automatically created 6to4 or 6rd routes. Delete the tunnel only after no production dependency remains. Finally, verify the earlier route and a known data flow again.

Checklist

• The selected type matches the inner and outer address families.
• Both endpoints and prefixes are agreed with the peer.
• The display name and immutable Hardware name are documented.
• Zone, static route, and return path match the security design.
• Automatically created 6to4 or 6rd routes were checked.
• A narrow firewall rule matches with the expected Firewall Rule ID.
• Outer encapsulation and inner application traffic were tested separately.
• MTU, HA, and rollback were validated on the real path.

Frequently asked questions