Sophos Firewall IPv6 support and limitations in SFOS 22

Sophos Firewall supports IPv6 in SFOS 22 for essential networking, routing, VPN, rule, protection, and diagnostic features. A completely IPv6-only deployment is still not realistic for every environment. WAF rules, IPv6 resolution in FQDN host objects, the integrated Let’s Encrypt feature, Up2date, RED, remote access IPsec, RIPng, and multicast have documented limitations.

Before a rollout, it is therefore not enough to verify that an interface receives an IPv6 address. The decisive question is whether every feature in the actual end-to-end path supports IPv6. Where a required feature is unavailable, dual stack or a deliberately planned IPv4 path is usually safer than forcing an IPv6-only architecture.

This article puts the official SFOS 22 IPv6 support matrix into an operational context. The linked specialist articles retain the detailed configuration of prefix delegation, routing, VPN, and rules.

Check an IPv6 design in seven steps

1. Document the exact SFOS build, provider connection, prefix, and every required service.
2. Split the complete path from the client or sender to the destination into individual functions: interface, addressing, DNS, routing, rule, protection module, VPN, portal, and update path.
3. Check each function against the SFOS 22 support limits in this article.
4. Define a deliberate IPv4 or alternative product path for unsupported dependencies. Never work around a missing feature with a broad rule or Any.
5. Configure IPv6 interfaces, Router Advertisement, routes, objects, and firewall rules separately from IPv4.
6. Test the address, default route, Neighbor Discovery, DNS, Route Lookup, Rule ID, Packet Capture, and the actual service one after another.
7. Switch to production only after positive and negative tests pass; retain the IPv4 fallback and previous rule order until then.

⚠️ A check mark in the Sophos support matrix confirms product support, not a complete configuration or functional parity with IPv4. A successful IPv6 ping proves neither DNS, policy, protection profile, VPN, nor application function. Conversely, a documented unsupported feature does not become supported through service restarts, hidden CLI options, or a broader firewall rule.

What the support matrix actually means

The current Sophos page was updated on January 8, 2026, and applies to the SFOS 22 Help. It separates features that can process IPv6 from features that still have no IPv6 support. This boundary is narrower than the general statement that the firewall supports IPv6.

Four layers must remain separate:

• Addressing: The interface has an IPv6 prefix and the client has a matching address.
• Routing: Forward and return paths point to the expected interfaces and gateways.
• Policy: A dedicated IPv6 rule permits only the planned traffic and logs the test.
• Service: The VPN, WAF, proxy, email, portal, or update function actually supports the IPv6 path.

A working layer does not prove the next one. This separation prevents a green interface status from being treated as evidence for a WAF or update feature that is not yet supported.

Network and addressing

Supported

• static IPv6 addresses on physical, bridge, alias, VLAN, and LAG interfaces;
• DHCP Prefix Delegation;
• DHCPv6 server, client, and relay, including dynamic and static leases;
• Neighbor Discovery Protocol (NDP) and Router Advertisement;
• DNS Lookup and Reverse Name Lookup;
• IPv6 tunnels using 6in4, 6to4, 6rd, and 4in6.

Unsupported or limited

• IPv6 over Cellular WAN;
• IPv6 PPPoE;
• Dynamic DNS over IPv6;
• DNS64;
• Tunnel Broker;
• RED hardware and Firewall RED tunnels between two Sophos Firewalls;
• DHCP Prefix Delegation on a LAG interface.

The prefix delegation guide explains the executable path from the provider prefix through the internal interface to Router Advertisement and firewall rules: Configure IPv6 Prefix Delegation on Sophos Firewall. For static prefixes, the interface, VLAN, and zone planning from Plan Sophos Firewall zones and interfaces correctly remains relevant.

DNS64 and NAT64 must not be confused. SFOS 22 lists DNS64 as unsupported. By contrast, the NAT64 path documented by Sophos is provided by the Direct Web Proxy and only for explicit HTTP/HTTPS proxy traffic. It is not a general protocol gateway.

Routing and multicast

Supported

• static IPv6 unicast routes;
• SD-WAN routes for IPv6;
• BGP IPv6 and OSPFv3;
• WAN Load Balancing;
• Upstream Proxy.

Unsupported

• RIPng;
• dynamic IPv6 multicast using Multicast Listener Discovery (MLD);
• static IPv6 multicast routes.

An IPv4 route does not automatically become an IPv6 route. The workflow for fixed networks is available under Configure static IPv4 and IPv6 routes. OSPFv3 is configured separately from OSPFv2, while the Router ID remains in IPv4 notation. The safe workflow and the absence of OSPFv3 authentication are described in Configure and verify OSPF on Sophos Firewall.

The existing Avanet articles about static multicast and PIM-SM cover IPv4. Their commands and menus must not be used to infer an IPv6 MLD or multicast workflow.

VPN

Supported

• site-to-site SSL VPN;
• remote access SSL VPN;
• site-to-site IPsec.

Unsupported

• remote access IPsec over IPv6;
• L2TP VPN over IPv6;
• PPTP VPN over IPv6.

For site-to-site IPsec, the connection can use IPv4, IPv6, or Dual with a route-based Any-to-Any connection. Dual requires separate IPv4 and IPv6 firewall rules and a deliberately planned routing path. The full tunnel type decision is documented under Configure a Sophos Firewall site-to-site IPsec VPN.

The statement remote access SSL VPN supports IPv6 does not mean that every resource, FQDN object, and full-tunnel path automatically works as dual stack. The pool, permitted resources, DNS, IPv6 rules, and actual client test remain separate checkpoints.

Rules, NAT, and protection modules

Supported

• zone-based IPv6 firewall rules;
• NAT66 and NAT64, with NAT64 available only in Proxy Mode;
• Server Load Balancing;
• SSL/TLS Inspection Rules;
• IPS, DoS Bypass Rules, and Spoof Protection;
• Web Filtering, Application Filter, and Malware Scanning;
• Zero-day Protection.

Unsupported

• WAF rules over IPv6;
• Wireless as an IPv6 protection path;
• the feature separately named Advanced protection in the Sophos matrix.

An IPv4 firewall rule does not permit IPv6 traffic. In Rules and policies > Firewall rules, select the IP version deliberately and validate the rule with Source, Destination, Service, Logging, and Rule ID. The fundamentals are covered in Understand and configure Sophos Firewall rules safely.

For IPv6-only clients accessing an IPv4-only web destination, use the separate proxy workflow NAT64 with Direct Web Proxy. It does not translate non-proxy traffic, UDP, ICMP, or applications without explicit proxy support.

Email, portals, and administration

Supported

• SMTP MTA and SMTP Proxy;
• IMAP Proxy and POP Proxy;
• WebAdmin, User Portal, and SSH;
• NTP and SNMP;
• Authentication Server.

Unsupported

• Quarantine Digest over IPv6.

IPv6 support for WebAdmin or SSH is not a recommendation to expose these services to the internet. Keep Device Access and the Local Service ACL tightly limited to the management network or known source networks. The IPv6 pilot must also confirm with a negative test that unplanned management sources cannot connect.

Diagnostics, objects, updates, and certificates

Supported

• Current Activities for users and connections;
• Ping, Traceroute, Name Lookup, Route Lookup, and Packet Capture;
• Syslog and Reporting;
• IPv6 IP Hosts;
• Traffic Shaping and QoS.

Unsupported or limited

• Policy Tester for IPv6;
• Country Hosts for IPv6;
• IPv6 resolution in FQDN host objects;
• Up2date Infrastructure over IPv6;
• the integrated Let’s Encrypt feature over IPv6.

The FQDN limitation applies to the SFOS host object: the firewall does not resolve IPv6 addresses for this object. This does not mean that DNS clients or Name lookup generally receive no AAAA responses. However, a dynamic IPv6 destination must not be designed around an FQDN host object as if SFOS automatically maintained its AAAA addresses.

The Let’s Encrypt limitation is also product-specific. It does not mean that ACME or certificates are generally IPv4-only. It means that the integrated SFOS feature must not be planned as an IPv6 path. A working IPv4 path therefore remains necessary for issuance, renewal, and Up2date while Sophos documents these limits.

Example of a controlled dual-stack pilot

The example separates production and replaceable values:

• provider prefix: 2001:db8:100::/48
• internal test network: 2001:db8:20:30::/64
• firewall in the test network: 2001:db8:20:30::1
• pilot client: 2001:db8:20:30::50
• controlled test destination: 2001:db8:40:50::20
• the IPv4 return path for management, Up2date, and Let’s Encrypt remains in place initially.

2001:db8::/32 is a documentation prefix and is not routed on the public internet. Replace every address with the provider prefix and controlled test systems from the real environment. The /64 is the planned example network for a normal client segment; the actual prefix allocation depends on the provider delegation and internal network plan.

Before the pilot, these decisions must be clear:

1. Which functions does the specific flow use?
2. Are all of them listed as supported in the SFOS matrix?
3. Is there an IPv4 fallback for updates, certificates, and management?
4. Which IPv6 rule should match, and which Rule ID is expected?
5. Which negative connection must remain blocked?
6. How will DNS, the return path, and the actual application service be tested?

Validate the IPv6 path

A reliable acceptance test proceeds from the bottom up:

1. Interface: Verify the expected IPv6 address and prefix on the WAN and internal interfaces.
2. Client: Check the IPv6 address, Prefix Length, and Default Route.
3. Neighbor Discovery: Under Network > Neighbors (ARP–NDP), verify the expected IPv6 neighbor and correct interface. The safe interpretation is explained in Check the ARP and NDP neighbor cache.
4. DNS: Check A and AAAA responses separately. A working A record does not prove an IPv6 path.
5. Routing: Use Diagnostics > Tools > Route lookup with the actual IPv6 destination and document both forward and return paths.
6. Policy: In Log Viewer, confirm the expected IPv6 rule, Action, and Firewall Rule ID. Because Policy Tester does not support IPv6, Log Viewer, Route Lookup, Packet Capture, and the real test flow are more important.
7. Packet flow: Packet Capture must show the packet entering and leaving through the expected interface. A packet visible only on ingress narrows the problem to routing, the rule, or a protection module.
8. Service: Positively test HTTPS, VPN, SMTP, DNS, or the specific application; ping alone is not sufficient.
9. Negative test: An unauthorized IPv6 source or unapproved service remains blocked.

The read-only Device Console commands for a controlled example path are:

ping6 2001:db8:40:50::20
traceroute6 2001:db8:40:50::20
dnslookup6 app.example.com

The documentation address and .example do not work in production and must be replaced with a controlled destination. These commands test reachability, path, and name resolution, but not a specific firewall rule or the application. Further safe basic commands are explained in Troubleshoot Sophos Firewall with basic commands.

Troubleshoot by symptom

The client receives no IPv6 address or Default Route

Check the provider prefix, WAN assignment, Delegated Interface, Router Advertisement, VLAN, and client segment. Do not continue experimenting with Prefix Delegation on a LAG because Sophos explicitly excludes this combination. Working IPv4 does not prove correct IPv6 addressing.

An IPv6 address is present, but the service does not work

Check the DNS response, NDP, Route Lookup, IPv6 rule, Rule ID, and return path first. Then investigate the service itself. Do not create a broad Any rule as a diagnostic substitute. If the required feature is unsupported in the matrix, move the path to IPv4 or another architecture.

The FQDN host object contains no IPv6 address

This is the documented product limitation. FQDN host objects in SFOS do not resolve IPv6 addresses. A static IPv6 IP Host can suit a stable, operationally maintained address; dynamic destinations require a new design decision. A broad destination object is not a safe replacement.

WAF, RED, or remote access IPsec must work over IPv6

These cases are unsupported in the current matrix. Stop the rollout before productively rebuilding rules, certificates, or tunnels. Retain IPv4 for that feature or choose a separately supported access path.

Updates or Let’s Encrypt fail in an IPv6-only network

According to the matrix, Up2date Infrastructure and the integrated Let’s Encrypt feature are unsupported over IPv6. Restore the intended IPv4 egress, DNS, routing, and rules first. Service restarts and new certificate requests do not fix missing product support.

Rollback

1. Disable the new IPv6 rules or restore the documented previous rule order.
2. Remove the pilot Router Advertisement, Delegated Interface, or static IPv6 assignment only within the planned maintenance window.
3. Retain or restore the previous IPv4 routes, DNS responses, and management access.
4. Remove temporary IPv6 host objects and test rules only after the return path has been confirmed.
5. Recheck IPv4 management, Up2date, certificate renewal, and the original service.
6. Preserve the failure time, build, interface, Route Lookup, Rule ID, and Packet Capture before opening a support case for a still-supported IPv6 path.

Checklist

• SFOS version and build documented.
• Every required feature checked against the current IPv6 support matrix.
• Unsupported dependencies have a deliberate IPv4 or alternative path.
• Prefix, /64 segments, Router Advertisement, and DNS planned.
• IPv4 and IPv6 rules created and logged separately.
• Device Access was not unintentionally expanded through IPv6.
• NDP, Route Lookup, Rule ID, Packet Capture, and the actual service verified.
• Positive and negative tests passed.
• Up2date and Let’s Encrypt still have a working IPv4 path.
• Rollback and independent management access documented.

FAQ