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.

The SFOS 23 help explains the automatic mechanism more precisely: 6to4 derives its IPv6 prefix from the local public IPv4 address. No remote endpoint is configured; the destination gateway is determined automatically from the destination IPv6 address. 6rd, in contrast, uses ISP-provided IPv6 prefixes and relay gateways. The firewall automatically determines the ISP-provided relay gateway. This requires a suitable 6rd service from the ISP; prefer native IPv6 when available. These mechanisms don’t change the legacy warning below.

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.

For 6to4, also distinguish the still-defined unicast mechanism from the public anycast relay mechanism. The IETF deprecated anycast 6to4 because of its operational problems and recommends that routers keep 6to4 disabled by default (RFC 7526). Don’t enable 6to4 for a new internet connection. At most, use it for an existing, explicitly coordinated unicast design; native IPv6 connectivity, provider-managed 6rd, or a fixed 6in4 peer are easier to control.

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 zone model and firewall rules must match the actual architecture. Device access controls access to services on the firewall itself and doesn’t replace a rule for forwarded application traffic.

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.

The underlay must carry an encapsulated IP protocol rather than a TCP or UDP port. 6in4, 6to4, and 6rd use IPv6-in-IPv4 with IPv4 protocol number 41 (RFC 4213); 4in6 follows the IPv6 tunnel model in RFC 2473 and identifies the inner IPv4 packet in the outer IPv6 header with IANA-registered Next Header value 4. Confirm this exact data path with the provider, upstream firewall, and any NAT device before deployment. Opening a port isn’t a substitute for that check.

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.

Other settings show this customizable interface name, not the immutable Hardware name.

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.

The complete documented restriction list for Hardware name in SFOS 22 and 23 is: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. The name must not contain any of these substrings; this isn’t limited to identical complete names. Spellings are preserved as documented, without inferring how case sensitivity is handled.

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 label Remote endpoint follows the SFOS 22 help. The SFOS 23 help calls this field Remote gateway: it accepts an IPv4 address or FQDN for 6in4, and an IPv6 address or FQDN for 4in6. An FQDN is the peer’s fully qualified DNS name, not the inner destination prefix. For Local endpoint, SFOS 23 describes an address associated with an interface (6in4/6to4), explicitly an associated IPv4 address for 6rd, and an IPv6 interface for 4in6. The local address family remains as described below. Different help wording doesn’t establish the exact release in which runtime support began.

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 specifies neither universal best values nor a default on the help page. Record the starting values shown in your own form and change them only when a specific underlay or QoS requirement calls for it.

These TTL/TOS basics follow the SFOS 22 help. The SFOS 23 help explains TTL as the maximum number of routers an encapsulated packet can traverse before it is discarded. This limit helps prevent routing loops. It likewise specifies no numeric TTL or ToS default.

For 4in6, SFOS 23 also describes these advanced settings:

• Inherit ToS is optional and uses the inner packet’s ToS value.
• MTU is the largest packet size in bytes that can cross the tunnel without fragmentation. The documented default is the physical interface MTU minus 48 bytes; the reduction accounts for 4in6 encapsulation overhead.
• Override MSS is optional and allows the MSS to be specified manually. MSS is the largest TCP payload in bytes within one TCP packet without fragmentation. Adjusting it can prevent fragmentation or accommodate path MTU limits. The documented default is the MTU value minus 40 bytes.

These formulas are documented values, not independent calculations from protocol overhead or lab-test results. No default enabled state is asserted for the optional checkboxes. Any adjustment still depends on the actual path.

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.

SFOS 23 API: schema and validation

This section describes the API documentation for Add IP Tunnel / Edit IP Tunnel, not the WebAdmin workflow or a tested request. Compared with the SFOS 22 documentation, the SFOS 23 parameter table adds four optional fields of type SCALAR:

• MSS: INTEGER, allowed range 536–8912, at most four digits.
• MTU: INTEGER, allowed range 576–8952, at most four digits.
• LocalInterface: STRING for the tunnel’s local interface; the Default cell is blank. This does not establish a runtime default.
• InheritToS: allowed values Disable and Enable.

The table does not establish whether every field applies to every tunnel type, precedence between LocalInterface and LocalEndPoint, required field combinations, or the release in which runtime support began. The WebAdmin endpoint and FQDN guidance is not carried over as an API compatibility promise.

API status 541 for Add and Edit

For both operations, SFOS 23 documents status 541 with the message MTU and MSS must not exceed the local interface values. MTU and MSS must therefore not exceed the corresponding local interface values. Before changing anything, compare the submitted MTU/MSS values, the associated local interface, and its recorded configuration. This API validation is not a measurement of data-path MTU and does not establish a general calculation relating MTU to MSS.

Conflicting defaults remain unresolved

The API table literally lists Default: Enable for MSS, although the field is described as an INTEGER with a numeric range. For InheritToS, it literally lists Default: off, although only Disable and Enable are listed as allowed values. These conflicting documentation values are not recommended payload values and are neither corrected nor reinterpreted as other tokens.

The API also lists an MTU default of 1500 and describes ToS inheritance from the local interface. In contrast, the WebAdmin help for 4in6 specifies physical interface MTU minus 48 bytes, MSS equal to MTU minus 40 bytes, and ToS inheritance from the inner packet. The mapping between these interfaces remains unresolved; the correct WebAdmin formulas and optional controls above remain unchanged.

Actionable automation guidance relying on these defaults, inheritance rules, or field precedence remains excluded. No executable API payload is provided here. This requires clarification from Sophos or an expressly authorized test on the matching SFOS version; the documented schema and status information is not a product test.

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.

For additional IPv6 routes after saving 6to4 or 6rd, SFOS 23 names the pop-up fields Destination IP (IPv6) and Gateway (IPv6). Enter the destination and gateway according to the network design and select Save; select Cancel if no additional route is needed. These IPv6 fields don’t apply to the inner IPv4 route of a 4in6 tunnel. Continue to observe the SFOS 22 warning about saved configuration when using Cancel.

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.

For the 6in4 example, go to Rules and policies > Firewall rules, select IPv6, and then select Add firewall rule > New firewall rule. Set Action: Accept, the actual Source zones, Source networks and devices, Destination zones, Destination networks, and Services, and turn on Log firewall traffic. Position the rule so that a broader rule doesn’t match first. Replies belonging to an allowed stateful connection don’t need a second rule. Create a separate, equally narrow rule only if the peer must be allowed to initiate new connections.

For a normal site connection, retain the original source address. Leave Create linked NAT rule clear; don’t enable MASQ as a substitute for a missing return path. SFOS passes allowed traffic untranslated when no NAT rule matches. If the design genuinely requires translation, plan and test it separately with the original and translated flows. 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. Under Diagnostics > Tools > Route lookup, enter the inner address 2001:db8:200::20 and confirm the expected tunnel 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. Under Diagnostics > Packet capture > Configure, enter host 192.0.2.10 and host 198.51.100.20 in Enter BPF string for the outer check and save it. Start the capture, generate exactly one test, and stop it again. For a separate inner capture, clear the BPF string under Configure and save it; then set Ethernet type: IPv6 and Destination IP: 2001:db8:200::20 under Display filter and save. Start the capture for one test only, then stop it.
7. At the peer, verify ingress, decapsulation, the return route, and the actual source address.
8. Test a new connection initiated by the peer only when a separate rule permits it; the stateful rule already covers reply traffic.

A tunnel entry proves neither the route nor reachability of 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.

According to the SFOS 23 help, deleting a 6to4 or 6rd tunnel also deletes its automatically created static IPv6 unicast route. This expectation doesn’t replace dependency checks or the before-and-after comparison. It doesn’t cover all manually added routes and isn’t extended to SFOS 22 solely on the basis of the SFOS 23 help.

For rollback, first stop test traffic and turn off the newly created firewall rule. Then delete only the manual routes created for this tunnel, or restore changed routes to their recorded starting state. Explicitly compare automatically created 6to4 or 6rd routes with the before-and-after record. Delete the tunnel only after no production dependency remains, then remove any automatic route that remains individually. Finally, use Route lookup to confirm the earlier path and test 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