DNS resolution fails on WSS Agent host due to overlapping SAC segment interception

Products

• Symantec ZTNA
• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Cloud SWG integrated with Secure Access Cloud, where segment applications hostnames are resolved by an internally configured SAC DNS server.

Host specified DNS server IP address, existing on a separate internal network segment, overlaps with intercepted SAC ranges.

Users accessing Secure Access Cloud segment applications using WSS Agent or SEP Web and Cloud Access Protection will always resolve hostnames correctly using SAC DNS server.

Users accessing internet sites will fail after a tunnel has been established and authenticated - as DNS resolution for public sites will fail.

Environment

WSS Agent version 9.1.1+  / SEP Agent Windows RU7+ / SEP Agent macOS RU6+
DNS server overlaps with intercepted SAC ranges and exists on a separate network segment from the device.
Cloud integration with ZTNA.

Cause

WSS Agent will automatically not route traffic on a local network segment to Secure Access Cloud (SAC) even if it has been selected for interception.  This works for most environments where internal (RFC-1918) addresses are used for a device’s DNS server.
However, some environments will host the DNS server in a separate network segment from the device.  In these scenarios, if SAC is configured to intercept the address the DNS server exists on, DNS traffic will be sent through the WSSA tunnel to a (usually non-existent) DNS server on the customer network, leading to DNS errors while the tunnel is connected.

Consider the following example:

• Device receives an IP address of 10.2.138.15 with a network mask of 255.255.255.0 (10.2.138.0/24).
• DNS server is located at 10.1.12.5
• SAC is configured to intercept traffic destined for 10.0.0.0/8 (everything in the class A RFC-1918 subnet)

In this configuration, traffic destined to 10.2.138.0/24 will NOT be intercepted or sent through the tunnel.  This is due to WSS Agent giving preference to the local network segment over SAC traffic.

However, the DNS requests destined for 10.1.12.5 WOULD be intercepted and sent through the tunnel to the customer network.  Likely, the customer network will not have a DNS server at this address responding to queries.  It is possible that another server exists at this address performing a different function.  As such, the DNS request will fail.

Resolution

There are four workarounds to this scenario:

• Enable the Cloud SWG DNS Proxy.  This will cause all DNS requests to be intercepted and sent through the tunnel, instead of being delivered to the configured DNS server
• Change the DNS server on the device to one that is not intercepted by SAC (i.e. 8.8.8.8 or 1.1.1.1)
• Bypass the problematic DNS server by IP address in the Cloud SWG portal.  This will cause traffic destined for that address to be delivered to the DNS server and never be delivered to the customer network via SAC.
• Configure SAC to ONLY intercept traffic that has a corresponding application server listening on it.  Avoid capturing large blocks of traffic (such as /8 or /16 CIDR ranges).