how Internet based anonymous proxies and open VPN traffic will be handled WRT Geo. while com

SOLVED
Keval
Here to help

how Internet based anonymous proxies and open VPN traffic will be handled WRT Geo. while com

One of our client would like to know how Internet-based anonymous proxies and open VPN traffic will be handled wrt Geolocation while coming into the data center. The example used – Someone from Egypt uses a proxy such that it appears they are trying to connect from NYC. How will this is situation be handled? Also, to what level can Geolocation be configured i.e. country, state, etc.?

 

What would be a solution for this on Meraki VMX on the Azure cloud?

keval parsaniya
1 ACCEPTED SOLUTION
Bruce
Kind of a big deal

Hi @Keval, geolocation is based on the mapping of IP addresses to countries, and then effectively applying ACLs to those IP addresses - but you don't have to do any of that manually, you just have to select the country/countries you want to block traffic to/from (you can do this on the Layer 7 firewall rules). The geolocation database is dynamically updated which is why this is part of the Advanced Security license since it requires an ongoing update.

 

With regards to anonymous proxies and the like, its unlikely to effective. If you consider the IP address of the traffic from the MXs perspective it will be to/from the proxy, and so it will only be able to place the location of the proxy, not the destination. You'd need to prevent the clients using anonymisers too, this could be done with Layer 3 firewalls if you can identify the IP addresses, or you'll have to use something which has more granular categorisation of traffic (e.g. Cisco Umbrella) as the MX doesn't provide a dynamically updated category for anonymisers.

 

Also be aware that the VMX doesn't support the advanced security features (unless this has changed recently) and so this geolocation functionality wouldn't be available on a VMX hosted on Azure anyway.

 

I'd also use a reasonable amount of caution with geolocation too. It can work, but it can also cause problems. The database updates aren't fool-proof and you can't always be sure of where servers are located. My son was pretty upset when he was prevented from playing Rocket League because the online logon was redirecting to a server that was supposedly located in China.... 

View solution in original post

1 REPLY 1
Bruce
Kind of a big deal

Hi @Keval, geolocation is based on the mapping of IP addresses to countries, and then effectively applying ACLs to those IP addresses - but you don't have to do any of that manually, you just have to select the country/countries you want to block traffic to/from (you can do this on the Layer 7 firewall rules). The geolocation database is dynamically updated which is why this is part of the Advanced Security license since it requires an ongoing update.

 

With regards to anonymous proxies and the like, its unlikely to effective. If you consider the IP address of the traffic from the MXs perspective it will be to/from the proxy, and so it will only be able to place the location of the proxy, not the destination. You'd need to prevent the clients using anonymisers too, this could be done with Layer 3 firewalls if you can identify the IP addresses, or you'll have to use something which has more granular categorisation of traffic (e.g. Cisco Umbrella) as the MX doesn't provide a dynamically updated category for anonymisers.

 

Also be aware that the VMX doesn't support the advanced security features (unless this has changed recently) and so this geolocation functionality wouldn't be available on a VMX hosted on Azure anyway.

 

I'd also use a reasonable amount of caution with geolocation too. It can work, but it can also cause problems. The database updates aren't fool-proof and you can't always be sure of where servers are located. My son was pretty upset when he was prevented from playing Rocket League because the online logon was redirecting to a server that was supposedly located in China.... 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels