Transparent Proxy Solution for Sites With No Default Route and/or No Public DNS resolution
McAfee Web Gateway Cloud Service (WGCS) and McAfee Web Gateway can indeed work with authentication from locations with no default route and no external DNS resolution. The key is to take advantage of McAfee Client Proxy (MCP) and its unique capabilities.
If clients are configured to use a proxy they will expect the proxy to resolve the address for the site and then no public address resolution is required. Proxy requests can be intercepted and redirected to WGCS or McAfee Web Gateway (MWG) by MCP.
MCP is currently the only effective, completely transparent, and reliable method to authenticate individual users and groups to WGCS. Two things are required to make this work in environments that don't allow DNS resolution of public addresses:
Configuring Client to Use a Proxy and MCP to Redirect Web Traffic Destined for Configured Proxy
MCP must be installed on the client. MCP, when active, needs to intercept 80, and 443 to work offnet, and intercept proxy port traffic when on net. It should be configured to bypass for all private addresses except MWG addresses or other proxy destinations used in the PAC file. Any public addresses that have routes and can be sent direct per PAC or WPAD file should also be bypassed in the MCP policy
Reaching one of the proxies configured in the MCP Policy
To activate MCP needs to be able to reach WGCS SaaS service public address on 80 or 8080 per MCP policy. For mobile clients, it is always recommended to list <customerID>.saasprotection.com on port 80 first so that MCP redirection to WGCS works when off net.
Allowing MCP to reach WGCS when on a network with no public address resolution and no default route can be accomplished in many, many ways, here a few that are fully supported by McAfee:
Here are some that should work but are not fully supported.
Note: Hard-coding to a WGCS PoP IP rather than using DNS to resolve the current public address is not supported. IPs of PoPs can change and availability of a given PoP IP is not subject to the SLA for availability. There are many reasons that a specific IP may become unavailable (maintenance or service outage are a couple) and the DNS based WGCS Global Routing Infrastructure is designed to accommodate that without service interruption. The risk of using hard-coded IPs can be mitigated if you have internal MWGs that can be reached if MCP can't reach any of its configured WGCS proxies. (Either configure internal MWG proxies last in MCP policy list , or leave your MWGs as primary in the PAC file or as failover in return string, or as specific proxy and they will be used directly when MCP is inactive.)
Important Note: Again, if you do not have MWGs that will get the traffic if MCP is inactive (because it can't reach the service), be sure to take that into consideration when you plan your configuration. If you are addressing WGCS by fixed IP, any given IP could be taken offline at any time due to maintenance or an outage, if you aren't using the global routing infrastructure via DNS, then you need to handle this in your MCP policy configuration and your firewall DNATs
Here is a diagram:
This is a tested configuration that is fully supported if using IPsec tunnel or if public IPs of PoPs are ultimately resolved through DNS. Comments and suggestions welcome.
Note that when MCP is intercepting traffic destined for a proxy, MCP policy domain based bypasses and IP based bypasses will not work. Domain and policy based bypasses will continue to work for traffic that is sent direct.
See also this recent article on using PAC files with MCP and taking advantage of the newer Alternate Proxy feature of MCP: Using-MCP-In-Environments-with-PAC-Files Also of interest are the links in that article and How Can I Apply UCE Policy to Traffic Directed to a Local MWG