cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 1 of 4

Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Route?

Jump to solution

McAfee KB article https://kc.mcafee.com/corporate/index?page=content&id=KB87232 details all of the possible addresses that can be returned for the saasprotection.com and wgcs.mcafee-cloud.com domains. This KB article is kept continuously updated and is the official reference maintained and supported by McAfee. However, currently it does not supply mutually exclusive address mapping to specific physical locations which makes static routing for full tunnel VPN or on premise devices using explicit proxy or MCP with centralized DNS a challenge. How can this be addressed?

Update 1/12/2021. The KB referenced above now includes physical locations! My replies below updated accordingly.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?
3 Solutions

Accepted Solutions
jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 4

Re: Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Rou

Jump to solution

McAfee KB article https://kc.mcafee.com/corporate/index?page=content&id=KB87232 details all of the possible addresses that can be returned for the saasprotection.com and wgcs.mcafee-cloud.com domains. This KB article is kept continuously updated and is the official reference maintained and supported by McAfee.

The SLA for the cloud service is contingent upon use of FQDN for obtaining the address of the PoP to be used for a given client. In order to obtain best performance through multiple global egresses, regional DNS should be used at each egress and ALL possible McAfee IP addresses should be routed and allowed through any firewalls that are in path. Ideally for VPN clients all McAfee IP addresses should be allowed direct.

The addresses provided by McAfee Global Routing Manager are dependent on the geolocation (currently determined from Maxmind) of the DNS server that is making the query against the root server that is the authority for these domains. For customers that have centralized DNS, this can be a problem.

McAfee Client Proxy (MCP) 3.2 attempts to address the centralized DNS problem by having the initial PoP send back to MCP the actual public address that the client is using. MCP can then use that address as a prefix to a second DNS resolution that will resolve to the best PoP for the client’s actual source address (again currently based on Maxmind) rather than the address of the DNS server. This is fantastic and works great for mobile clients if the client is using an egress proximal to the client itself, even if the DNS server is elsewhere. However, proximal egress is often not the case in a full, or limited, split tunnel VPN, or when on a corporate network with limited egress points.

If all the possible egress addresses within the corporate network are known, then MCP could be configured to use a prefix of the form c<customerID>.ip4-<IPv4 address in hex of egress>.<saasprotection.com or wgcs.mcafee-cloud.com> for each egress and put all addresses in the MCP proxy list choosing fastest response time and a list that would look something like this (if customer ID was 123 and the WGCS service was in use managed by MWG or Cloud ePO):

c123.saasprotection.com

c123.ip4-b97de001.saasprotection.com (185.125.224.1 (b97de001) will usually map to an address in Nuremburg 185.125.224.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b97de101.saasprotection.com (185.125.225.1 (b97de101) will usually map to an address in Miami 185.125.225.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b97de201.saasprotection.com (185.125.226.1 (b97de201) will usually map to an address in London 185.125.226.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b97de301.saasprotection.com (185.125.227.1 (b97de301) will usually map to an address in Frankfurt 185.125.227.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-a1457a01.saasprotection.com (161.69.122.1 (a1457a01) will usually map to an address in Las Angeles 161.69.122.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-a1457b01.saasprotection.com (161.69.123.1 (a1457b01) will usually map to an address in New York 161.69.123.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b9dd4401.saasprotection.com (185.221.68.1 (b9dd4401) will usually map to an address in Sydney 185.221.68.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b9dd4501.saasprotection.com (185.221.69.1 (b9dd4501) will usually map to an address in Singapore 185.221.69.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b9dd4601.saasprotection.com (185.221.70.1 (b9dd4601) will usually map to an address in Tokyo 185.221.70.0/24, or a nearby /24 or /32 address from the full list)

The addresses above should usually yield addresses in or near each of the 9 peering PoPs because the prefixes used are peering PoP addresses.

As another example, if a customer has egresses in NYC, Tokyo, Singapore, and Berlin

c123.saasprotection.com

c123.ip4-<IPv4 address of Berlin egress in hex>.saasprotection.com

c123.ip4-<IPv4 address of NYC egress in hex>.saasprotection.com

c123.ip4-<IPv4 address of Singapore egress in hex>.saasprotection.com

c123.ip4-<IPv4 address of Tokyo egress in hex>.saasprotection.com

Note that when using actual regional egress addresses in the prefix, it is possible that the geolocation mapping of that egress address could be wrong which would then result in the return of a suboptimal PoP address. It is also more likely to get individual addresses outside of the larger CIDR blocks. As such, it is critical that the client always has the most efficient route available and is permitted to reach ANY address from the FULL list on the designated port in the proxy configuration or MCP proxy list(s). It is recommended that if global routing tables are in use, that EVERY address from the FULL McAfee list is routed out the nearest egress per the KB article. If there are no localized default routes on the corporate network, static routes through the nearest egress should be added any time an address is added to the McAfee public list. Addresses added to the McAfee public list should also be added to VPN client exception lists if MCP is being used.

While MCP has long had the ability to choose the fastest response time from a list of possible proxies, those proxies will be identified by using DNS.  If all addresses are routed out of the same egress rather than the egress closest to the PoP, then the best PoP for that common egress will always be chosen, and this feature has no value. Therefore, it is critical that a client on the corporate network has efficient routes to EVERY possible PoP address through the egress closest to that PoP.

Continued in next reply due to character limitations.....

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 3 of 4

Re: Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Rou

Jump to solution

Continued from reply above

As of 1/12/21 the list now provides physical geographic locations hosting the inbound addresses and this is specific enough for establishment of static routes assigned in networks that do not include default routes and fully localized egresses. (tables now removed from replies) Note that virtual PoP addresses will often have ingress and egress addresses registered in a different country even though the ingress address and the actual PoP hosting that address is in the geographic (physical) location as indicated in the KB. The KB article should always be the primary reference as it is the official McAfee list. The KB is kept current and is updated in advance as changes are planned for the global infrastructure.

 

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 4

Re: Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Rou

Jump to solution

Just added to production GRM _stable_cidr prefix will only serve addresses from the four large McAfee owned CIDR blocks. 

161.69.112.0/20

185.125.224.0/22

185.221.68.0/22

185.212.104.0/22

The prefix can be used in combination with other prefixes like ip4 and/or region prefixes. 

Examples:

_stable_cidr.c<customerid>.wgcs.mcafee-cloud.com

_stable_cidr.ca.c<customerid>.saasprotection.com

_stable_cidr.ip4-b97de001.c<customerid>.wgcs.mcafee-cloud.com

_stable_cidr.ip4-b97de001.ca.c<customerid>.wgcs.mcafee-cloud.com

Note that restricting PoP address usage means that the SLA no longer applies.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

3 Replies
jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 4

Re: Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Rou

Jump to solution

McAfee KB article https://kc.mcafee.com/corporate/index?page=content&id=KB87232 details all of the possible addresses that can be returned for the saasprotection.com and wgcs.mcafee-cloud.com domains. This KB article is kept continuously updated and is the official reference maintained and supported by McAfee.

The SLA for the cloud service is contingent upon use of FQDN for obtaining the address of the PoP to be used for a given client. In order to obtain best performance through multiple global egresses, regional DNS should be used at each egress and ALL possible McAfee IP addresses should be routed and allowed through any firewalls that are in path. Ideally for VPN clients all McAfee IP addresses should be allowed direct.

The addresses provided by McAfee Global Routing Manager are dependent on the geolocation (currently determined from Maxmind) of the DNS server that is making the query against the root server that is the authority for these domains. For customers that have centralized DNS, this can be a problem.

McAfee Client Proxy (MCP) 3.2 attempts to address the centralized DNS problem by having the initial PoP send back to MCP the actual public address that the client is using. MCP can then use that address as a prefix to a second DNS resolution that will resolve to the best PoP for the client’s actual source address (again currently based on Maxmind) rather than the address of the DNS server. This is fantastic and works great for mobile clients if the client is using an egress proximal to the client itself, even if the DNS server is elsewhere. However, proximal egress is often not the case in a full, or limited, split tunnel VPN, or when on a corporate network with limited egress points.

If all the possible egress addresses within the corporate network are known, then MCP could be configured to use a prefix of the form c<customerID>.ip4-<IPv4 address in hex of egress>.<saasprotection.com or wgcs.mcafee-cloud.com> for each egress and put all addresses in the MCP proxy list choosing fastest response time and a list that would look something like this (if customer ID was 123 and the WGCS service was in use managed by MWG or Cloud ePO):

c123.saasprotection.com

c123.ip4-b97de001.saasprotection.com (185.125.224.1 (b97de001) will usually map to an address in Nuremburg 185.125.224.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b97de101.saasprotection.com (185.125.225.1 (b97de101) will usually map to an address in Miami 185.125.225.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b97de201.saasprotection.com (185.125.226.1 (b97de201) will usually map to an address in London 185.125.226.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b97de301.saasprotection.com (185.125.227.1 (b97de301) will usually map to an address in Frankfurt 185.125.227.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-a1457a01.saasprotection.com (161.69.122.1 (a1457a01) will usually map to an address in Las Angeles 161.69.122.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-a1457b01.saasprotection.com (161.69.123.1 (a1457b01) will usually map to an address in New York 161.69.123.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b9dd4401.saasprotection.com (185.221.68.1 (b9dd4401) will usually map to an address in Sydney 185.221.68.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b9dd4501.saasprotection.com (185.221.69.1 (b9dd4501) will usually map to an address in Singapore 185.221.69.0/24, or a nearby /24 or /32 address from the full list)

c123.ip4-b9dd4601.saasprotection.com (185.221.70.1 (b9dd4601) will usually map to an address in Tokyo 185.221.70.0/24, or a nearby /24 or /32 address from the full list)

The addresses above should usually yield addresses in or near each of the 9 peering PoPs because the prefixes used are peering PoP addresses.

As another example, if a customer has egresses in NYC, Tokyo, Singapore, and Berlin

c123.saasprotection.com

c123.ip4-<IPv4 address of Berlin egress in hex>.saasprotection.com

c123.ip4-<IPv4 address of NYC egress in hex>.saasprotection.com

c123.ip4-<IPv4 address of Singapore egress in hex>.saasprotection.com

c123.ip4-<IPv4 address of Tokyo egress in hex>.saasprotection.com

Note that when using actual regional egress addresses in the prefix, it is possible that the geolocation mapping of that egress address could be wrong which would then result in the return of a suboptimal PoP address. It is also more likely to get individual addresses outside of the larger CIDR blocks. As such, it is critical that the client always has the most efficient route available and is permitted to reach ANY address from the FULL list on the designated port in the proxy configuration or MCP proxy list(s). It is recommended that if global routing tables are in use, that EVERY address from the FULL McAfee list is routed out the nearest egress per the KB article. If there are no localized default routes on the corporate network, static routes through the nearest egress should be added any time an address is added to the McAfee public list. Addresses added to the McAfee public list should also be added to VPN client exception lists if MCP is being used.

While MCP has long had the ability to choose the fastest response time from a list of possible proxies, those proxies will be identified by using DNS.  If all addresses are routed out of the same egress rather than the egress closest to the PoP, then the best PoP for that common egress will always be chosen, and this feature has no value. Therefore, it is critical that a client on the corporate network has efficient routes to EVERY possible PoP address through the egress closest to that PoP.

Continued in next reply due to character limitations.....

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 3 of 4

Re: Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Rou

Jump to solution

Continued from reply above

As of 1/12/21 the list now provides physical geographic locations hosting the inbound addresses and this is specific enough for establishment of static routes assigned in networks that do not include default routes and fully localized egresses. (tables now removed from replies) Note that virtual PoP addresses will often have ingress and egress addresses registered in a different country even though the ingress address and the actual PoP hosting that address is in the geographic (physical) location as indicated in the KB. The KB article should always be the primary reference as it is the official McAfee list. The KB is kept current and is updated in advance as changes are planned for the global infrastructure.

 

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 4

Re: Routing, VPN and Firewall Rules for WGCS/UCE PoPs - Using MCP or Explicit Proxy - No Default Rou

Jump to solution

Just added to production GRM _stable_cidr prefix will only serve addresses from the four large McAfee owned CIDR blocks. 

161.69.112.0/20

185.125.224.0/22

185.221.68.0/22

185.212.104.0/22

The prefix can be used in combination with other prefixes like ip4 and/or region prefixes. 

Examples:

_stable_cidr.c<customerid>.wgcs.mcafee-cloud.com

_stable_cidr.ca.c<customerid>.saasprotection.com

_stable_cidr.ip4-b97de001.c<customerid>.wgcs.mcafee-cloud.com

_stable_cidr.ip4-b97de001.ca.c<customerid>.wgcs.mcafee-cloud.com

Note that restricting PoP address usage means that the SLA no longer applies.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community