0 Replies Latest reply on May 2, 2017 1:28 PM by jebeling

    Transparent Proxy Solution for Sites With No Default Route and/or No Public DNS Resolution

    jebeling

      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:

      1. The client browser or app must be proxy aware and configured to use an explicit proxy
      2. MCP client proxy must be able to reach one of the proxies configured in its policy

       

      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

      • Using existing PAC file (that is designed to redirect to MWG when on prem)
        • Don’t use generic bypass of public addresses
        • Instead use bypass of all but MWG proxy addresses
        • Add specified proxy port (9090 default) to intercept list
      • Modifying PAC file
        • Add 8.8.8.8:80 (or some other public address:80)  as first entry in PAC proxy return string
          • Doesn’t matter what address, or port, you use, as long as the address and port aren’t in bypass list
          • Add proxy port to MCP intercept list if you haven’t used 80 or 443 in your policy definition for the proxy
      • Modify the direct proxy setting
        • Use 8.8.8.8:80 (or some other public address:80) as entry in browser configs
          • Doesn’t matter what address or port you use, as long as the address and port aren’t in MCP bypass list,
          • Add proxy port to MCP intercept list if you haven’t used 80 or 443 in your policy definition for the proxy

       

      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:

      • Could resolve proxy address in MCP policy locall to public address of WGCS and add static routes to address using firewall as gateway with appropriate rules to allow the traffic.
      • Could resolve proxy in MCP policy locally to local firewall address and each firewall could be set up with policy based routing using an IPsec tunnel to best WGCS PoP for IPsec (redundant IPsec tunnels highly recommended)
      • Could resolve proxy in MCP policy locally to local firewall address and have firewall redirect DNAT to <customerID>.saasprotection.com (if supportedby firewall)
      • Use any of the above methods with multiple host records for same name and resolve to firewall address based on best match (supported natively by Microsoft DNS servers) to requesting IP and have same record entries apply globally

       

      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.)

       

      • Could resolve proxy in MCP policy locally to local firewall address and local firewall VIP service DNAT to a public address of WGCS port 80 (not supported by McAfee due to hardcoding IP, but if you have MWG to failover to this will not cause issues)
      • High availability (highly recommended that some form is used especially if your firewall is DNAT to a fixed POP IP and you don't have MWG to failover to!) (not supported by McAfee due to hardcoding of IPs, but if you have MWG to failover to this will not cause issues)
        • Could resolve wgcsprimary.company.com locally via DNS to local firewall address:80 and local firewall VIP service DNAT to WGCS public address port 80
        • Could resolve wgcssecondary.company.com locally via DNS to second local firewall address:80 and local firewall VIP service DNAT to different public address port 80
        • Could just have multiple MCP policy entries using same FQDN that resolves to same set of local firewall addresses, but use different ports to direct to different public addresses.
        • Could just resolve wgcs.company.com locally to per site to correct firewall address use different ports DNAT’d to different POP IPs for redundancy (multiple generic proxy names in MCP policy using different ports translated to different IPs at firewall)
        • Could distribute different MCP policy by region using <customerID>.saasprotection.com as first proxy, local firewall addresses or names that resolve to them as subsequent entries

       

      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:

      FCA-MCP Arch.JPG

      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.