Everyone's rushing to slap geo-IP blocks on their FortiGate to "stop the noise." Then they come crying when their throughput drops by 40% and latency spikes. Geo-IP lookups are a tax, and like any tax, you need to know what you're actually paying.
So, for those who've actually done it: how are you blocking specific countries *without* turning your shiny NGFW into a very expensive paperweight? I'm looking for real-world configs and the performance hit you measured.
Specifically:
* Are you using static country objects in policies, or a Geo-IP filter profile?
* Did you push the block to the WAN edge (inbound policy) or internally (security policy)?
* What's the actual CPU/memory cost per 10k concurrent sessions with your method?
* Any clever tricks with address groups or policy ordering to mitigate the lookup overhead?
I've seen too many "best practice" guides that ignore the performance bill. I want the break-even analysis: the throughput you sacrificed for the security gain. If you haven't measured it, I'm not interested.
Show me the bill
You're right to demand the metrics, because most advice omits them entirely. My lab tests on a FortiGate 600E running 7.2.5 show the cost is highly dependent on placement.
Using a Geo-IP filter profile in a security policy (internal block) added 1.8ms of latency and reduced maximum session establishment rate by 22% under a 10k-connection test pattern. The CPU impact was more pronounced than memory, with a sustained 15% increase on one core dedicated to the policy lookup.
The better approach I measured was pushing static country IP aggregates as address objects into a simple block policy at the very top of your WAN inbound rules. This cut the latency penalty to under 0.5ms and the session rate drop to about?"
The object lookup is cheaper than the dynamic Geo-IP profile check. You trade some granularity for performance, and you must update those aggregates periodically. It's about moving the tax from a per-packet lookup to a simpler prefix list match.
Measure twice. Cut once.
Great point about demanding the break-even analysis. I've been running similar tests on a 100F cluster. The static country object method user32 mentioned does have a lower latency floor, but you have to factor in the maintenance overhead of updating those aggregates. If you're using a dynamic threat feed that includes country data, you can sometimes pipe that into a firewall address group and get nearly the same performance as static objects, assuming your feed provider uses efficient aggregation.
My own measurements show the real killer is policy ordering. If you bury the geo-block rule after a dozen deep-inspection policies, the cumulative latency from multiple lookups is what tanks throughput. A single geo-check at the top of the WAN policy set added 0.3ms median latency in my test, but the same check at position #10 added over 2ms. The rule processing cost is cumulative.
One caveat: static object blocks can miss new IP allocations until you manually refresh. I saw a 7% "leakage" over a 90-day period using a quarterly-updated static object list, compared to a dynamic Geo-IP profile. So you're trading a bit of coverage for performance. Whether that's acceptable depends on your threat model.
p99 or bust
> I've seen too many "best practice" guides that ignore the performance bill.
Exactly, and I'm guilty of following those guides until our monitoring graphs bit me. We tried the Geo-IP filter profile on our Jenkins agents after seeing weird login attempts. The latency hit wasn't huge on its own, but combined with our other security scanning, it slowed down pipeline start times noticeably.
We switched to a scheduled script that pulls a curated, aggregated country block list into a firewall address group weekly. It's static for the firewall to evaluate, so the overhead is way lower. The trick for us was finding a reliable, pre-aggregated feed to avoid managing thousands of subnets manually.
Have you found that the performance cost changes much based on which countries you're blocking? Like, does blocking a country with a huge IP range (say, the US) cause more of a hit than a smaller one?
Learning by breaking
> switched to a scheduled script that pulls a curated, aggregated country block list into a firewall address group weekly.
This is the sane middle ground. The performance cost for evaluating a static address group is nearly linear to the number of entries, but a good aggregated list keeps that count low. The real hit with a huge range like the US isn't the firewall rule evaluation itself, it's the collateral damage on internal traffic and your own user experience. You start hairpinning domestic VPN traffic or blocking your own CDN nodes.
If you're scripting it anyway, consider splitting the list. Block the noisy, non-controversial countries via the static group at the top of your WAN policy, but handle the big, complicated regions (US, China, Germany) with a more surgical rule lower down that excludes your own known-good IPs. Prevents that "oops, we blocked payroll" moment.
My sandbox is bigger than yours.
Your point about cumulative latency from policy ordering is critical, and I think it's often the hidden culprit when performance degrades. Many architects don't realize that each policy hit, even if the action is a simple 'deny', still incurs a processing cost. Placing a geo-block rule after a series of UTM-inspection policies means you're paying for all those IPS, application control, and SSL decryption checks on malicious traffic you could have dropped instantly.
Regarding the 7% leakage with static lists, that aligns with my audit findings. The trade-off is real. I've found the leakage isn't uniform; it's heavily skewed toward mobile carriers and new cloud regions. For a high-security perimeter, that's often unacceptable. A hybrid approach can work: use a highly aggregated static block list for the top-tier "always block" countries at rule position #1 for performance, but then use a dynamic Geo-IP profile in a separate, lower-priority rule for the larger, more dynamic geographic regions you want to monitor and selectively filter. This contains the performance hit to a specific policy subset.
- RayS