Using Geolocation in Firepower Access Control Policies

The use of geolocation is fairly obvious in monitoring networks with Firepower Management Center. What may be less obvious is that Continents and Countries can also be specified as the source or destination of connections in an Access Control Policy. Basically, this geographical information becomes one more match criteria that can be used to identify traffic for a block or allow action.

To get to this capability, open the Access Control Policy that is in use by the Firepower device. Within the policy, open or create an applicable rule. On the network tab (where you configure the source and destination addresses) a Geolocation tab can also be found. Clicking on this tab exposes Continents and Countries. These can be added as sources and/or destinations.


Note to reader: All Firepower content can be accessed by clicking here (or choosing Firepower from the menu at the top of the page).

As can be seen in the diagram above, I am creating a rule to block traffic to France. Before I save and deploy the policy changes to the device, I will confirm reachability to an IP address that exists in that part of Europe.

Last login: Mon Jul 17 11:48:29 on ttys000
PAULS:~ pauls$ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=237 time=115.456 ms
64 bytes from icmp_seq=1 ttl=237 time=121.466 ms
64 bytes from icmp_seq=2 ttl=237 time=126.173 ms
64 bytes from icmp_seq=3 ttl=237 time=116.089 ms
64 bytes from icmp_seq=4 ttl=237 time=118.776 ms
64 bytes from icmp_seq=5 ttl=237 time=115.351 ms
64 bytes from icmp_seq=6 ttl=237 time=114.532 ms
--- ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 114.532/118.263/126.173/3.930 ms

After saving the changes and applying the policy to the device, I will test to make sure the traffic is blocked.

PAULS:~ pauls$ ping
PING ( 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
--- ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss


Geolocation is a parameter that might not be an obvious option, but a useful addition to the match criteria of an Access Control Policy. I’m always curious to what extent others are using this feature and if any caveats have surfaced.

If you have feedback to share or other tips or tricks for maintaining and operating a Firepower solution, please share them by commenting below.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.

2 Responses to Using Geolocation in Firepower Access Control Policies

  1. Daniel Cook says:

    Hi Paul, one thing worth noting for non-US companies with corporate websites is that Google (amongst) others use bots based in the US to index and rank pages on their search engines. In our case we decided to block non UK connections and the website disappeared from Google’s rankings due to bot innacessabilty. Perhaps fairly obvious in hindsight but worth mentioning all the same!

    • Very good comment here. This is one of those things that makes a ton of sense after it impacts your service. That is a good point for inbound filtering. Regarding outbound connections, CDNs can also exist in pretty much any geo. Thanks for the feedback.

Comments are closed.