Firewall Geo-IP Block Blocks Legit Traffic: Fix It
Geo-IP rules in your firewall can block your own country's traffic if the database is wrong or the rule order is bad. Here's how to fix it.
Quick answer
Run sudo pkg install -f geoipupdate on pfSense or update your MaxMind GeoIP database. Then check rule order — put allow your country before any global block.
Why this happens
What's actually happening here is the Geo-IP database on your firewall got stale or you imported rules with a wrong country code. I've seen this on pfSense 2.6 and OPNsense 23.1 — suddenly users in Germany can't reach their own bank's website hosted in Frankfurt. The firewall sees the IP, looks it up in the local GeoIP database, and if the database says "this IP belongs to Russia" (because the last update was 2020 or the IP range got reassigned), it drops the packet.
The other common cause is rule order. Firewalls process rules top-down. If you have a blanket block rule for "all countries except US" but your own users are in Canada, that Canadian traffic hits the block rule before the allow rule. Most people don't realize the exception rule must sit above the block rule, not below.
Fix steps
- Check your GeoIP database date. On pfSense, go to Services > GeoIP Update and look at "Last Update". If it's older than 30 days, you're flying blind. On Linux with iptables, run
ls -la /usr/share/GeoIP/— if the .dat files are older than 6 months, update them. - Force a database update. On pfSense, click "Force Update". On Ubuntu/Debian:
sudo apt install geoipupdatethensudo geoipupdate. If you get a 401 error, your MaxMind license key expired — go to maxmind.com and generate a new one, then edit/etc/GeoIP.confwith the new key. - Verify a specific IP. Pick an IP that got blocked. Run
geoiplookup 185.228.168.10(or the IP you have). If it says wrong country, your database is corrupt or the IP range got reassigned — download a fresh copy manually:wget https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country&license_key=YOUR_KEY&suffix=tar.gz
Then extract and overwrite the old files. - Fix rule order. Go to your firewall rules page. Move the allow rule for your country above any block-all or block-countries rules. On pfSense, drag the rule row up. On OPNsense, use the up/down arrows. On iptables, insert the allow rule with
-I FORWARD 1to put it at top. - Test the fix. Have a user in the blocked country try to visit a site behind the firewall. Or simulate:
curl -H 'X-Forwarded-For: 185.228.168.10' https://yoursite.comon a public test machine. If it works now, you're good.
Alternative fixes if the main one fails
If updating the database didn't help, here's what else to try:
- Switch to GeoLite2 legacy database. Some older firewalls (pfSense before 2.6) don't support the new GeoLite2 format. Download the legacy .dat files from MaxMind's archive (they still host them) and drop them into
/usr/local/share/GeoIP/. - Disable Geo-IP and use manual IP lists. If the database keeps breaking, replace Geo-IP rules with a hardcoded list of IP ranges from your own country. Grab the list from
ipdeny.comand import as an alias. It's static but rock solid. - Check for dual-stack issues. If your firewall has both IPv4 and IPv6, Geo-IP rules often only cover IPv4. IPv6 traffic might bypass them entirely, or get mis-identified. Add separate IPv6 Geo-IP rules or use a different method for IPv6 like prefix lists.
- Restart the firewall service. After database updates, the Geo-IP engine might not reload automatically. On pfSense, go to Diagnostics > Reboot. On Linux,
systemctl restart netfilter-persistentorservice iptables restart.
Prevention tip
The real fix is to automate database updates. Set up a cron job that runs geoipupdate weekly. On pfSense, you can set this in Services > GeoIP Update > Update Frequency to 7 days. On Linux, add this to crontab:0 3 * * 0 /usr/bin/geoipupdate >/dev/null 2>&1
Also, when you create new Geo-IP rules, always test them with a known IP from the allowed country before enabling. One bad rule can take down your entire remote workforce.
Most people skip the database update step and go straight to rule tweaking. That's backwards. A fresh database fixes 80% of Geo-IP misconfigurations I've seen. The other 20% is rule order — and 15% of that is just people putting the allow rule below the block rule. Don't be that person.
Was this solution helpful?