Ensuring secure access via SSL VPN for dual-stack users

Ensuring secure access via SSL VPN for dual-stack users

I ran into this on a Sophos XGS with an IPv4-only WAN and dual-stack clients on the other end. IPv4 went through the SSL VPN tunnel. IPv6 did not. That was enough to make IP-based controls behave in different ways depending on which address family the client picked.

Challenges with dual-stack configuration

Dual-stack clients can split traffic by protocol. A remote laptop may send IPv4 through the SSL VPN tunnel and send IPv6 straight out via the client WAN. That looks fine on the client, but it breaks policies that expect one office IP. I saw a 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. Someone tried changing the SSL VPN lease mode to hand out IPv6 addresses. That stopped the health heartbeat and triggered internal firewall blocks because the XGS had no IPv6 egress to translate or route the traffic.

The pattern is straightforward. The VPN expects a full tunnel. The client OS prefers IPv6 where it can. The appliance has no IPv6 path on the WAN. The result is inconsistent access and odd blocks.

Importance of network security

If the client is meant to behave like it is in the office, the controls need to work the same way too. IP-based allow lists, heartbeat checks, and firewall rules have to see the traffic in a predictable way. If IPv6 escapes the tunnel, those controls do not cover it. That leaves gaps in access control and makes incident response messier than it needs to be.

Overview of VPN configuration options

When the WAN is IPv4-only and the clients are dual-stack, there are four sensible paths:

• Prefer IPv4 on the client so target services use the tunnel.
• Use split DNS so internal services resolve to A records only.
• Provide IPv6 on the office WAN or another IPv6-capable egress for VPN traffic.
• Use an IPv6 NAT64/DNS64 or proxy egress that takes IPv6 from the client inside the tunnel and sends IPv4 towards the internet, or the other way round.

The first two are quick and targeted. The last two need changes at the edge or extra infrastructure, but they are cleaner if you want dual-stack to behave properly.

Best practices for SSL VPN dual stack users

Configuring Sophos XGS for dual stack

On XGS, start with the SSL VPN global settings. If the WAN is IPv4-only, do not hand out IPv6 to clients unless there is an IPv6 route or some other egress path that can carry the traffic. Handing out IPv6 without egress can break heartbeat and internal access checks.

If IPv6 WAN or routed IPv6 is available, 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 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 it back and check the IPv6 route tables and firewall rules.

If IPv6 egress is not available, leave the SSL VPN lease mode on IPv4 only and use the 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 the internal resolver. Split DNS works well here. If gitlab.example.com only has an A record from internal DNS, the client will use IPv4.
• Adjust client name resolution order: on Windows, change prefix policy to prefer IPv4 for specific destinations. On Linux, tweak gai.conf to prefer IPv4 for particular hosts.
• Use host files for tight control on machines that need fixed behaviour. It is blunt, but it works for a small set of critical hosts.
• If client-side changes are not practical, 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 small proxy that accepts IPv6 from the client and sends IPv4 out.

Each method changes where the traffic exits. Pick the one that makes the destination service see the office IP 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.

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

Where heartbeats or SSO depend on source IP, check that the source address seen by the service matches what you expect. If it does not, trace the path and see whether IPv6 left the tunnel.

Implementing firewall rules for dual stack

Treat IPv6 as another address family that needs rules. If IPv6 is accepted for SSL VPN clients:

• Add matching IPv6 firewall rules for the SSL VPN zone.
• Mirror IPv4 internal allow lists with IPv6 equivalents.
• Check NAT behaviour for IPv6. If clients should hit the internet via office IPv6, configure the right translation or routing.

If IPv6 egress is not available, deny routed IPv6 for the SSL VPN network. That is clearer than hoping the lack of a route will keep the flow contained.

Testing and troubleshooting connection issues

Test with a dual-stack client and work through it in order:

1. Check the 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 on Windows tracert -6 and tracert -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 disappears after IPv6 is enabled, roll back and inspect route tables and firewall rules for the IPv6 path.

Write down a reproducible test case. It saves time when the same mess shows up again.

Monitoring and maintenance strategies

Add these checks to routine monitoring:

• Monitor heartbeat status for SSL VPN clients and alert on drops.
• Log and review outbound addresses for critical services where IP matters.
• Test periodically from a known dual-stack client to confirm the behaviour still matches expectations.
• Keep a short runbook: how to flip lease modes, how to add IPv6 rules, how to roll back.

If IPv6 is opened on the edge later, rehearse the change in a lab first. Roll it out in stages to a small set of users and services. Watch the logs for anything that now sees IPv6-origin traffic.

If the WAN does not have IPv6, do not hand out IPv6 inside the tunnel unless there is a route or NAT path for it. The quickest fixes are DNS and client-side IPv4 preference. Longer term, an IPv6-capable egress is the cleaner answer if you want dual-stack remote access to behave properly.