Ensuring secure access via SSL VPN for dual-stack users

I run labs and help fix awkward network edge problems. I wrote this guide after wrestling with a Sophos XGS on an IPv4-only WAN while clients had dual-stack internet. I keep it practical. No fluff. Read it, test the steps, pick the option that matches your constraints.

Introduction to SSL VPN Dual Stack

Challenges with Dual-Stack Configuration

Dual-stack clients can split traffic by protocol. A remote laptop may send IPv4 via the SSL VPN tunnel and IPv6 directly out the client WAN. That looks normal to the laptop, but it breaks policies that rely on a single office IP. I saw this in a reported case where an IPv4-only XGS office allowed access when the remote host used IPv4, but blocked the same service when the client used IPv6 from its home ISP. Changing the SSL VPN lease mode to hand out IPv6 addresses was tried. The change stopped the health heartbeat and triggered internal firewall blocks because the XGS had no IPv6 egress to translate or route that traffic.

This mismatch is the common problem. The VPN wants a full tunnel. The client OS may prefer IPv6. The appliance may not have IPv6 reachability on the WAN. The result is inconsistent access and weird blocks.

Importance of Network Security

Treat VPN clients like they are physically in the office. That means IP-based allow lists, heartbeat checks, and firewall rules must work the same for remote hosts as for local hosts. If some client traffic bypasses the tunnel on IPv6, those protections no longer apply. That creates blind spots for sessions and complicates incident response. Protecting the office edge means either forcing all traffic through the tunnel, or making off-tunnel traffic subject to the same controls at a different egress point.

Overview of VPN Configuration Options

You have four realistic paths when the WAN is IPv4-only but clients are dual-stack:

• Prefer IPv4 on the client so both stacks use the tunnel for target services. This is the quickest fix for specific hosts.
• Force DNS to resolve only A records for in-office services, so clients use IPv4. Use split DNS if needed.
• Run IPv6 on the office WAN or provide an IPv6-capable egress for VPN traffic. This is more work but removes the split.
• Provide an IPv6 NAT64/DNS64 or proxy egress that accepts IPv6 from the client inside the tunnel and sends IPv4 to the internet, or vice versa.

Each option has trade-offs. The first two are simple and surgical. The last two are more robust but need changes at the edge or additional infrastructure.

Best Practices for SSL VPN Dual Stack Users

Configuring Sophos XGS for Dual Stack

On XGS, check the SSL VPN global settings first. If your WAN is IPv4-only, do not hand out IPv6 to clients unless you have an IPv6 route or an egress path that can handle that traffic. Handing out IPv6 without egress will break heartbeat and internal access checks in some cases.

If you do have IPv6 WAN or a routed IPv6 path, create a dedicated IPv6 network for SSL VPN clients. Assign addresses from a ULA or routed prefix, add the network to the SSL VPN configuration, and add IPv6 routes on the appliance. Update the SSL VPN policy so that the IPv6 subnet is part of the full tunnel. Then check that health heartbeat packets travel over the assigned address family. If heartbeat stops, roll back, check route tables and firewall rules for the IPv6 path.

If you cannot provide IPv6 egress, leave SSL VPN lease mode on IPv4 only. Use the other mitigations below to stop IPv6 bypass.

Managing IPv4 and IPv6 Traffic

Control the client’s choice between IPv4 and IPv6.

• Use DNS: return only A records for office services on your internal resolver. Split DNS works fine here. If gitlab.example.com only has an A record from your internal DNS, the client will pick IPv4.
• Adjust client name resolution order: on Windows, change the prefix policy to prefer IPv4 for specific destinations. On Linux, you can tweak gai.conf to prefer IPv4 for particular hosts.
• Use host files for tight control on machines that need guaranteed behaviour. This is blunt, but effective for a small set of critical hosts.
• If client-side change is not possible, add an IPv6-capable egress in the office. That could be a cloud VM with dual-stack and a tunnel back to the XGS, or a lightweight proxy that accepts IPv6 from the client and sends IPv4 to the internet.

Each method changes where traffic exits. Pick the one that gives the same office IP to the destination service when that service relies on IP allow lists.

Ensuring Consistent Access for Users

Make the client appear to services as if it comes from the office IP. That means:

• Force the client to use IPv4 for verification-sensitive services.
• Offer split DNS so internal names only resolve to IPv4 inside the VPN.
• Use application allow lists that accept both office IPv4 and any authorised IPv6 egress if you have it.

Where heartbeats or SSO rely on source IP, validate that the source address seen by the service matches expectations. If it does not, trace the path to confirm whether IPv6 escaped the tunnel.

Implementing Firewall Rules for Dual Stack

Treat IPv6 like another address family that needs rules. If you accept IPv6 for SSL VPN clients:

• Add matching IPv6 firewall rules for the SSL VPN zone.
• Mirror any IPv4 internal allow lists with IPv6 equivalents.
• Verify NAT behaviour for IPv6. If you want clients to hit the internet via office IPv6, configure appropriate address translation or routing.

If you cannot provide IPv6 egress, deny routed IPv6 for the SSL VPN network to stop ambiguous flows. Explicit deny rules are better than relying on absence of routes.

Testing and Troubleshooting Connection Issues

Test with a dual-stack client. Check these items in order:

1. IP assignment inside the tunnel. Confirm whether the client received an IPv4 and/or IPv6 lease.
2. Run traceroute for both families. Use traceroute -6 and traceroute -4 or Windows tracert -6 and -4 to see the path.
3. Ping internal services by address and by name. Check which address family the client chooses.
4. Check Sophos logs: connection log, heartbeat log, and packet capture on the SSL VPN interface.
5. If heartbeat is missing after enabling IPv6, revert and inspect route tables and firewall rules for the IPv6 path.

Record a reproducible test case. That saves time if the issue recurs.

Monitoring and Maintenance Strategies

Add these checks to a basic monitoring routine:

• Monitor heartbeat status for SSL VPN clients. Alert on drops.
• Log and review outbound addresses for critical services where IP matters.
• Periodically test from a known dual-stack client to confirm expected behaviour.
• Keep a short runbook: how to flip lease modes, how to add IPv6 rules, how to rollback.

If you open IPv6 on the edge later, rehearse the transition in a lab. Run a staged rollout with a limited set of users and services. Watch the logs for any services now seeing IPv6-origin traffic.

Final takeaways: if your WAN lacks IPv6, do not offer IPv6 inside the tunnel unless you can route or NAT it. The fastest fixes are DNS and client preference for IPv4. Longer term, plan an IPv6-capable egress if you want true dual-stack parity for remote clients.