Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Products & Solutions

IPv6: End-to-End Forwarding to Zscaler and Simplified Deployment

image

IPv6 adoption is growing, but its uneven rollout in the internet requires enterprises to manage a long coexistence of IPv4 and IPv6. For organizations, the goal is to provide a consistent, secure experience for all their users. Initially, Zscaler Client Connector tunneled traffic over the IPv4 internet, and ZIA proxied to IPv4 or IPv6 destinations as necessary. This approach supported dual-stack and v6-only users but required reliance on NAT64/DNS64 at the edge for v6-only clients to reach v4-only services.

New End-to-End IPv6 Capabilities

In order to help our customers to transition to IPv6 more easily, Zscaler has introduced new capabilities to allow v6-only clients to communicate directly over IPv6 to the Zscaler service VIPs, maintaining the same inspection and policy enforcement.

  • End-to-End IPv6 to Zscaler Service VIPs: Zscaler Client Connector now resolves and uses IPv6 VIPs for PAC and TLS/DTLS tunnels, establishing control connections directly over IPv6. On the egress path, Zscaler still prefers IPv4 towards dual-stack destinations but will forward IPv6 traffic for IPv6-only destinations.
  • New IPv6 Service Domains: Parallel IPv6 service FQDNs, such as gateway6..net and pac6..net, have been introduced. These domains resolve to IPv6 VIPs in enabled data centers, allowing Zscaler Client Connector to use available IPv6 service endpoints and making rollouts more predictable.

Traffic Flow

The traffic flow for the new native IPv6 capability is as follows:

  1. Client to Service Ingress: Zscaler Client Connector resolves the PAC/gateway using the new "6" domains over IPv6 and establishes a control connection to the SSL VPN (SVPN) IPv6 VIP. IPv6-enabled edge devices and load balancers direct the connection to the appropriate SVPN node at the Zscaler Datacenter.
  2. Inside the Cloud: The inner customer packet remains IPv6 to the Service Edge, which decapsulates the packet, enforces policy (URL, Firewall, Cloud App, etc.), and forwards the traffic toward the destination.
  3. To the Destination: Dual-stack destinations are accessed over IPv4, which is preferred over IPv6. Zscaler forwards IPv6 traffic to destinations that are IPv6-only. IPv4-only destinations remain accessible as always, over IPv4. 

DNS Observation Table

The following table illustrates what DNS records users will observe depending on the client and destination types:

 

Client

Destination

DNS A record

DNS AAAA Record

 v4

 v4+v6

 Yes

 No Ipv6 record

 v4

 v4

 Yes

 No Ipv6 record

 v4

 v6

 Empty

 Native IPv6

 v4 + v6

 v4+v6

 Yes

 Empty

 v4 + v6

 v4

 Yes

 Empty

 v4 + v6

 v6

 Empty

 Native IPv6

 v6

 v4+v6

 N/A

 Native IPv6

 v6

 v4

 N/A

 DNS64

 v6

 v6

 Empty

 Native IPv6

Admin Configuration: What to Enable

Forwarding IPv6 natively to Zscaler requires only a small set of administrative changes:

  1. ZIA Tenant Prerequisites:
    • Ensure your tenant has the required IPv6 licenses (Advanced).
    • Enable IPv6 for the tenant under Administration → IPv6 in your ZIA Admin portal.
  2. Firewall and Traffic Controls:
    • Allow IPv6 DNS traffic (on by default).
    • Change the “Block IPv6 All” rule from Block/Drop to Allow so IPv6 flows are permitted and inspected.
  3. Zscaler Client Connector Version: For Windows, 4.8+ version and for MacOS, 4.7+ versions are required.
  4. Zscaler Client Connector Platform Setting (New):
    • Enable “IPv6 resolution for Zscaler domains” per platform in the Zscaler Client Connector admin portal. This controls whether Zscaler Client Connector resolves the new "6" service domains (e.g., gateway6, pac6).
  5. Zscaler Client Connector Forwarding and App Profiles:
    • Forwarding Profile: Continue to use Z-Tunnel 2.0 (or 1.0) as appropriate with no change in forwarding method selection.
    • Application Profile:
      • For Windows and MacOS, include 2000::/3 in the IPv6 inclusion list to route all global unicast IPv6 flows through Zscaler Client Connector. If IPv6 inclusion is left blank, IPv6 traffic may flow direct (fail open).
      • Keep standard exclusions for ULA, link-local, and multicast.
      • For Tunnel 2.0 environments forwarding DNS to ZIA, set DNS inclusion to “*” to forward all DNS traffic to Zscaler.
  6. PAC Considerations:
    • If your PAC uses tokenized variables like $GATEWAY, enabling “IPv6 resolution for Zscaler domains” allows Zscaler Client Connector to automatically prefer the correct "6" domains.
    • If your PAC hard-codes hostnames or IPs, plan to update them to the new "6" service FQDNs in IPv6-upgraded regions. Avoid hard-coding IPs during the rollout.

Rollout Strategy and Migration

  • The need for "subclouds" to enforce connections to specific data centers diminishes as gateway6/pac6 are enabled and Zscaler Client Connector automatically resolves to v6-capable DCs when "IPv6 resolution for Zscaler domains" is active.
  • Continue to prefer service FQDNs in PAC files, over fixed IPs for a smoother rollout.
  • Ensure all pre-requisites listed in the section above are met.
  • Start with a few test users, ensuring all the cases are met before rolling out the change to all users.
  • Validate key use cases, including Dual-stack, IPv4-only, and policy controls on IPv6 traffic. Once validated, you can reduce reliance on local NAT64 for cloud ingress.

Design Guidance and Caveats

  • Do not bypass v4-only destinations for v6-only clients unless the direct path includes NAT64.
  • Be explicit about IPv6 inclusions by including 2000::/3 in your Zscaler Client Connector App Profile configuration to ensure IPv6 flows are serviced by Zscaler.
  • Ensure IPv6 firewall controls are ordered correctly (e.g., QUIC block rules before broad IPv6 allows).
  • For v6-only clients, IPv4-only servers in Z-Tunnel 2.0 DNS Exclusions will not get a NAT64 prefix IPv6 address and will not be resolvable.
  • Similarly, an IPv4-only server in ZT2 IPv4 Exclusions with a NAT64 prefix IPv6 address from DNS Inclusions will not be accessible without ZIA Z-Tunnel 2.0.
  • Additionally, v6-only clients cannot connect to literal IPv4 addresses (e.g., http://8.8.8.8/).

Conclusion 

These enhancements provide a cleaner, more native experience for v6-only clients by enabling IPv6 all the way to Zscaler service VIPs. A few administrative changes - enabling IPv6 resolution for Zscaler domains, allowing IPv6 traffic, and setting appropriate IPv6 inclusions - are sufficient to deliver a seamless user experience, reduce local NAT64 reliance, and keep policy enforcement consistent.

To learn more about the native IPv6 forwarding capabilities to Zscaler, refer to the Zscaler help documentation.

Glossary

  • v4-only: Refers to a client or destination that exclusively uses the Internet Protocol version 4 (IPv4) for communication.
  • v6-only: Refers to a client or destination that exclusively uses the Internet Protocol version 6 (IPv6) for communication.
  • Dual-stack: Refers to a client or destination that is configured to run both IPv4 and IPv6 protocols simultaneously, allowing communication with both IPv4 and IPv6 systems.
form submtited
Thank you for reading

Was this post useful?

Disclaimer: This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.