Set up NAT64 on Sophos Firewall with Direct Web Proxy

An IPv6-only client can access a website that only has an IPv4 address through the Sophos Firewall Direct Web Proxy. SFOS resolves the destination name in the proxy and establishes the downstream connection over IPv4. This requires two firewall rules: an IPv6 rule from the client to the proxy and an IPv4 rule from the proxy to the destination.

This is not general layer 3 NAT64 for arbitrary protocols. It only works for HTTP and HTTPS connections that browsers or applications explicitly send to the web proxy. This workflow doesn’t create a regular NAT64 rule under Rules and policies > NAT rules.

The complete classification is available in Sophos Firewall IPv6 support and limitations in SFOS 22. SFOS supports this proxy-based NAT64 path but lists DNS64 as unsupported; this does not create a general transition for other protocols.

⚠️ The two rules have different responsibilities. For IPv6-only endpoints, the web policy and user matching belong in the IPv6 rule. Application Control, IPS, and other security features for the outgoing IPv4 connection belong in the IPv4 rule. A single broad rule doesn’t make this separation reliably visible.

NAT64 through the proxy in eight steps

1. Select a managed IPv6-only pilot client and a controlled A-only web destination.
2. Verify the IPv6 address, DNS, proxy FQDN, and TCP listener of the Direct Web Proxy.
3. Prepare the base setup for Direct Web Proxy, Device Access, and the PAC file or browser policy.
4. In the IPv6 view, create a logged rule from the pilot network to the proxy port with destination zone WAN.
5. Set the web policy and, if required, Match known users in this IPv6 rule.
6. In the IPv4 view, create a second logged rule from the proxy to the IPv4 destination with HTTP/HTTPS.
7. Test with a destination that has no AAAA record and check both Firewall Rule IDs and the web filter decision.
8. Add more clients only after positive and negative tests; validate rollback, HA, and SD-WAN separately.

Why two firewall rules are required

The data path changes IP version at the proxy:

1. The client connects to the firewall’s proxy listener over IPv6.
2. The IPv6 rule evaluates the client, user, destination name, proxy port, and web policy.
3. The proxy resolves the requested hostname.
4. If the destination only has an A record, the proxy creates a new IPv4 connection.
5. The IPv4 rule evaluates this second segment and applies Application Control or IPS, for example.

The second connection is no longer the client’s original IPv6 packet. The IPv4 rule must therefore not be designed as if the IPv6 client address had to appear as its source. At the same time, a successful IPv6 rule alone doesn’t prove that the proxy can actually reach the IPv4 destination.

Sophos calls this design a NAT64 scenario. Unlike a classic NAT64 gateway, however, it doesn’t route an IPv6 prefix for arbitrary IPv4 destinations. Applications without explicit proxy support, UDP, ICMP, and other non-proxy traffic aren’t translated by this workflow.

Set up Direct Web Proxy with a PAC file explains the general listener, PAC, Device Access, and rollback configuration. This article assumes that the basic proxy path works and only adds the IPv6-to-IPv4 transition.

Example and replaceable values

The workflow uses a small pilot:

• IPv6-only client: CLIENT6-PROXY-01
• Pilot network: 2001:db8:20:30::/64
• Firewall IPv6 address in the client network: 2001:db8:20:30::1
• Proxy FQDN: fw01.corp.example
• Proxy port: TCP 3128
• Controlled A-only destination: v4-test.corp.example
• Documented destination address: 192.0.2.80
• IPv6 rule: LAN6_DirectProxy_to_IPv4
• IPv4 rule: Proxy_IPv4_Egress_Pilot
• Web policy: Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24, and .example are documentation ranges. They don’t work as production addresses and must be replaced with the organization’s IPv6 prefix, the actual firewall address, and a controlled DNS name. The pilot client must genuinely use IPv6 only; a parallel IPv4 path would invalidate the test.

The test destination needs an A record but no AAAA record. A small internal web server or controlled test virtual host is best suited for this purpose. A random public website is unsuitable because its operator can enable IPv6 or change DNS responses at any time.

Configure IPv6 Prefix Delegation explains how the WAN prefix, router advertisement, and DHCPv6 work together. NAT64 doesn’t repair missing IPv6 addressing in the client network.

Verify the prerequisites

Four separate foundations must work before creating the rules:

• The client has a valid IPv6 address, default route, and working DNS.
• fw01.corp.example returns the intended AAAA response for the firewall in the client network.
• Direct Web Proxy listens on the documented port under Web > General settings > Web proxy configuration, 3128 in this example.
• The firewall has a working IPv4 WAN path to the destination.

Under Administration > Device access, Web proxy must be reachable for the specific client source and intended firewall address. A broad allowance for the entire LAN or Wi-Fi zone isn’t required for a pilot. The proxy boundary remains important: an allowed client can use this path to reach local HTTP/HTTPS services on the firewall. The management destinations are therefore tested explicitly as negative cases, as described in the base article.

The client receives the proxy FQDN and port through a managed browser policy, operating system setting, or PAC file. The FQDN must be reachable from the IPv6-only client over IPv6. An IPv6-only client can’t use a proxy address that only has an A record as its first hop.

Document existing firewall rules, web policies, authentication, TLS inspection, and SD-WAN routes. Position the two pilot rules high enough to be evaluated before a more general matching rule, without unintentionally overriding existing security rules.

Create the IPv6 rule to the proxy

Under Rules and policies > Firewall rules, first select IPv6, then create a rule using Add firewall rule > New firewall rule:

• Rule name: LAN6_DirectProxy_to_IPv4
• Action: Accept
• Log firewall traffic: enabled
• Source zones: LAN
• Source networks and devices: IPv6 pilot network or individual pilot client
• Destination zones: WAN
• Destination networks: controlled FQDN destination, or the deliberately planned destination set for the later rollout
• Services: custom TCP service for 3128
• Match known users: only with authentication that already works and the intended users or groups
• Web filtering > Web policy: Web_Standard_IPv6_Pilot

The destination zone WAN initially seems unusual because the client technically connects to a firewall address. However, Sophos requires WAN or Any to hand traffic to the proxy component. According to the vendor, this also applies when the final web server is in LAN or DMZ. Don’t change the destination zone to the physical server zone based on assumption.

Sophos also permits Any under Services. The specific listener port is easier to understand for a pilot and avoids an unnecessarily broad allowance. If the Web proxy listening port changes, the service, PAC/browser setting, Device Access, and tests must all use the same value.

For IPv6-only endpoints, configure user and group settings in this IPv6 rule. The web policy also applies here. The guide to firewall rules explains rule order, logging, and user matching; categories and actions are planned under Web Protection policies.

Create the IPv4 rule from the proxy to the destination

Next, switch to IPv4 under Rules and policies > Firewall rules and create the second rule:

• Rule name: Proxy_IPv4_Egress_Pilot
• Action: Accept
• Log firewall traffic: enabled
• Source zones: Any
• Source networks and devices: Any
• Destination zones: WAN
• Destination networks: initially the controlled A-only destination, later only the destinations that are actually required
• Services: HTTP and HTTPS, or the destination ports that are genuinely required
• Match known users: don’t use this as a substitute for user matching in the IPv6 rule for this IPv6-only workflow
• Other security features: intended Application Control, IPS, and, if required, traffic shaping policy

The official Sophos example uses Any for the source zone and source network because the proxy creates the IPv4 connection. Don’t incorrectly replace these values with the IPv6 client network. Instead, keep the pilot rule narrow through its destination and services and verify it by its Rule ID.

Don’t move the web policy to this IPv4 rule. It belongs to the first, user-related proxy segment. Application Control and IPS, by contrast, protect the segment between the proxy and IPv4 destination. A traffic shaping policy in the IPv4 rule applies to this egress; Sophos also documents that traffic shaping doesn’t apply to the direct connection between client and proxy.

Don’t create an additional NAT64 rule. The firewall’s regular IPv4 WAN path must still work. If an existing IPv4 rule already covers this proxy egress in a controlled manner, it can remain in use after checking its Rule ID and policies; a second parallel Any rule would then be worse than a deliberately documented existing rule.

Test the actual IPv6-to-IPv4 path

DNS and listener pre-check

The following read-only checks are useful on a Windows pilot client:

Resolve-DnsName fw01.corp.example -Type AAAA
Resolve-DnsName v4-test.corp.example -Type A
Resolve-DnsName v4-test.corp.example -Type AAAA
Test-NetConnection fw01.corp.example -Port 3128

The proxy FQDN must return the expected IPv6 address. The test destination must have an A record; the AAAA test is expected to return no destination address. Test-NetConnection only confirms the TCP listener, not the web policy, DNS resolution in the proxy, or IPv4 egress.

Validate both rules and security layers

1. Open a new private browser session on the IPv6-only pilot.
2. Verify the effective proxy or loaded PAC file.
3. Open the allowed A-only destination.
4. Open a destination deliberately blocked by Web_Standard_IPv6_Pilot.
5. In Log viewer, verify the IPv6 rule, source, user, web policy, action, and Firewall Rule ID.
6. For the downstream connection, verify the IPv4 rule, IPv4 destination, service, Application Control/IPS, and second Firewall Rule ID.
7. Repeat the destination request without the proxy as a negative test; the IPv6-only client must not reach the A-only destination directly over IPv4.
8. Test an application without proxy support and confirm that it isn’t mistakenly considered NAT64-capable.

Success is only proven when the destination name is genuinely A-only, the client reaches the proxy over IPv6, both expected rules match, and the allowed and blocked web tests show the planned actions. Test firewall rules systematically explains how to correlate Rule ID, Log Viewer, Policy Tester, and Packet Capture.

Troubleshoot systematically

The proxy port isn’t reachable over IPv6

Check the proxy FQDN’s AAAA response, client address, default route, Neighbor Discovery, firewall interface, and Web proxy under Device Access. A successful IPv4 test from another client says nothing about the IPv6 listener path.

The IPv6 rule matches, but the destination doesn’t load

First confirm that the proxy resolves the destination name to an A record and that the firewall itself has a working IPv4 WAN path. Then check the IPv4 rule, destination, service, order, and Rule ID. The IPv6 rule is only the first half.

Only dual-stack websites work

The NAT64 path hasn’t yet been proven. Check the test destination for an existing AAAA record. Use a dedicated A-only destination for acceptance and rule out an active IPv4 path on the client.

The web policy or user is incorrect

Check the assignment in the IPv6 rule. SFOS evaluates Match known users in both rules for IPv6-only endpoints, but Sophos explicitly assigns these settings to the IPv6 rule. User matching in the IPv4 rule must not substitute for missing user context in the first segment.

Application Control or IPS doesn’t apply

Check these features in the IPv4 rule, not only in the IPv6 rule. Then confirm through the IPv4 Rule ID that this rule actually processes the proxy egress. A successful web filter decision doesn’t prove Application Control or IPS.

Internal or local destinations behave unexpectedly

Even when the final destination is in LAN or DMZ, the IPv6 rule requires WAN or Any to hand traffic to the proxy. The actual destination zone is represented in the IPv4 rule. Also check the local management-service exposure caused by proxy access and the internal DNS responses.

SD-WAN, HA, and rollback

An SD-WAN route with HTTP and HTTPS services doesn’t match the client connection to proxy port 3128. The first segment must use the actual listener port or deliberately use Any. The proxy egress also needs a working WAN gateway or static return path. Set up and test SD-WAN routes explains these special cases.

In HA, don’t promise uninterrupted continuation of an existing proxy connection. After a controlled failover, open a new browser session and recheck the proxy AAAA record, IPv6 Rule ID, web policy, IPv4 Rule ID, and destination access. For log searches, use the node that processed the respective traffic.

For rollback:

1. Disable the pilot rules or restore them to the documented previous state.
2. Remove the dedicated Device Access exception for the pilot if it was created only for this test.
3. Remove the PAC, GPO, or browser proxy setting from the pilot.
4. Restore the previous IPv4/IPv6 rule order and SD-WAN configuration.
5. Recheck direct IPv6 access, existing proxy traffic, and local management services.

Don’t delete the two rules before documenting the previous path and ensuring that an open admin session or alternative management access is available.

Release checklist

• Client is demonstrably IPv6-only.
• Proxy FQDN returns the expected AAAA address.
• Test destination has an A record but no AAAA record.
• Direct Web Proxy and Device Access are restricted to the pilot.
• IPv6 rule uses destination zone WAN, the actual listener port, logging, and web policy.
• User matching, if required, has passed positive and negative tests in the IPv6 rule.
• IPv4 rule processes proxy egress with the planned destination ports and security features.
• Both Firewall Rule IDs and both IP versions are proven in the test.
• Management-service exposure, non-proxy traffic, SD-WAN, and HA are deliberately scoped.
• Rollback, owner, and review date are documented.

Frequently asked questions