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.

Quick workflow: Plan the inner destination network and outer endpoints separately, save the appropriate type under Network > IP tunnels > Add, and add the route, return route, and a narrow rule for the inner traffic. Then test a new application session and check outer encapsulation, decapsulation, and Rule ID separately. Save confirms the configuration, not a successfully tested data path.

⚠️ 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 covers the Add IP Tunnel / Edit IP Tunnel API fields. Resolve the installed build’s request syntax before writing; these fields are separate from the WebAdmin workflow. 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 authorised test on the matching SFOS version.

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.

4in6: Carry IPv4 payload traffic over IPv6

With 4in6, more than just the tunnel type changes compared with the 6in4 example. The outer endpoints are IPv6, while the routed networks and firewall rules are IPv4. A separate planning example uses 10.10.10.0/24 locally, 10.20.20.0/24 remotely, and 10.20.20.20 as the test server. The outer local interface address is 2001:db8:10::10, and the remote gateway address is 2001:db8:20::20. Replace the private IPv4 networks and IPv6 documentation addresses with unique, non-overlapping inner networks and IPv6 endpoints that are actually reachable across the underlay.

1. First, check the IPv6 underlay path to 2001:db8:20::20. The route to the outer peer must use the underlay, not the tunnel you are about to establish with that peer. A successful ping alone does not prove that encapsulated IPv4 packets can be carried.
2. Under Network > IP tunnels > Add, select 4in6, set a unique name and Hardware name, and assign the planned Zone. In SFOS 23, under Local endpoint, select the IPv6 interface with the planned local address, and enter the remote IPv6 address under Remote gateway. Reverse the local and remote endpoints on the peer. Continue to observe the SFOS 23 settings for MTU, Override MSS, and Inherit ToS described above.
3. After Save, create an IPv4 route to 10.20.20.0/24 through the new tunnel interface under Routing > Static routes. Configure the return route to 10.10.10.0/24 on the peer. The IPv6 fields in the additional 6to4/6rd route dialog are not the template for this route.
4. Under Rules and policies > Firewall rules, select IPv4. Allow only the required connections from the local IPv4 network to the remote IPv4 network, set the actual zones and services, and enable Log firewall traffic. The IPv6 underlay addresses must not replace the inner IPv4 networks in this payload traffic rule. Unless address translation is intended, retain the source address.
5. Check 10.20.20.20 using Diagnostics > Tools > Route lookup, then start a new, allowed connection to this server from the local test client. Check decapsulation and the return path at the peer. After the test session ends, the inner IPv4 addresses and the expected Firewall Rule ID must appear in Log Viewer; during the session, use the capture to check the path directly.
6. For the outer capture in the capture workflow described below, use the BPF filter host 2001:db8:10::10 and host 2001:db8:20::20. For the separate inner capture, clear the BPF string again and select Ethernet type: IPv4 and Destination IP: 10.20.20.20 under Display filter. Capture only one test at a time, then stop the capture. Follow the same dependency checks described below for rollback, but in this case apply them to the IPv4 routes and rules created specifically for this tunnel.

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.

The outer host filter also captures other traffic between the endpoints. For the 6in4 example, therefore, look for packets with the expected outer IPv4 addresses and IP protocol 41; an ICMP ping between the same hosts is not proof of encapsulation. For 4in6, similarly check for an outer IPv6 packet containing an inner IPv4 packet. Only comparison with the inner capture and an actually successful application session demonstrates the complete path. Capture data can contain payload data and must only be stored securely or anonymized before sharing.

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.

Test traffic is missing from the outer capture

First, compare the active capture and display filters with the outer endpoints actually in use. If Remote gateway is an FQDN, check whether the firewall can resolve the name to the expected peer address with the correct address family for the tunnel type: IPv4 for 6in4, IPv6 for 4in6. The FQDN option alone establishes neither a specific DNS refresh interval nor uninterrupted failover when an address changes.

Then check whether the test client is actually sending traffic to the inner destination and reaching the firewall through its gateway. On the firewall, the routing decision for this destination must select the tunnel interface. If the appropriate encapsulation is visible locally but not at the peer, check the underlay path and its protocol allowances with the provider and upstream devices. Do not broadly expand rules to Any, and do not enable NAT experimentally as a substitute for narrowing down the cause. If the cause remains unresolved, use the SFOS version, both endpoint configurations, routes, and time-coordinated captures from both sides as the basis for escalation.

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