10-22-2024 02:26 AM
My network environment strictly only allows web traffic through a security appliance or service, therefore any traffic direct through the firewall is blocked.
Configuring my internal domain in domain management works for internal sites when internal but anything that points to the internet goes direct and is blocked by the firewall, how can this be overcome?
Any pac file can work out the IP address of the target and identify whether it's in a non-public IP range and make a decision from there, but the romaing client appears to be incapable.
10-25-2024 08:36 AM
(Assuming this is the legacy ERC roaming client or AnyConnect/Secure client with just DNS protection, and not using SWG proxies from a SIG license with SWG)
The roaming client will not intercept HTTP/S traffic, nor will it change how your OS or applications send the traffic. PAC files can determine the difference between public and private ranges, but more importantly, the PAC files contain instructions on how to connect to those destinations; if an appliance or service is required to access the Internet and isn't automatically picking up traffic that clients think they're sending direct to the Internet, that's called an "explicit" proxy configuration, as opposed to a "transparent" proxy. Explicit proxies can usually be configured directly in application/OS settings, through a dedicated PAC file, or can be distributed through automatic proxy detection (WPAD).
You can still configure a PAC file when the roaming client is installed, but you'll have to make sure the PAC file is instructing your clients to make a DNS lookup, calling functions like "dnsResolve()" or "isInNet()". If the PAC doesn't force clients to make their own DNS lookups, they're just going to ask the proxy to handle DNS lookups on their behalf, and you'll lose roaming protection/visibility/enforcement for that web traffic.
There's a knowledge base article with more guidance and examples here: https://support.umbrella.com/hc/en-us/articles/230563527-Using-Umbrella-DNS-with-an-HTTP-proxy
If using SWG proxies: The roaming module needs to be able to directly connect to the SIG proxies, their IP ranges are documented and must be excluded in the firewall. SWG on roaming cannot "chain" through another proxy or service to reach SWG. If you have an on-premise proxy that you'd like to have working in tandem with SWG, it is supportable -- you configure proxy chaining between that device and Umbrella, just look up proxy chaining in the Umbrella docs.
10-25-2024 08:56 AM
I can see I have been unclear: This is simple SIG on corporate network with only connections to SWG gateways allowed.
The problem is if internal DNS (e.g. externsite.internaldomain.com) resolves to an external address, the SWG is bypassed for the traffic because "internal domain" and gets blocked at the firewall.
10-25-2024 10:46 AM
Oh, that makes sense.
I can't think of any quick fixes for this, the client is more capable of "excluding" than "including" traffic. If joined to an Active Directory domain, the machine will always wildcard that as an Internal Domains exception. For other domain(s) affected, you could try _removing_ them from the Internal Domains list and relying on the "NXDOMAIN redirection" feature. The client will try to look up against Umbrella public resolvers first, and then query local resolvers as a fallback whenever getting an NX response. It could potentially cause a performance impact reaching internal resources, however.
Might be worth talking to the Support team about that one, see if they can brainstorm any other workarounds.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide