pfBlockerNG GeoIP: MaxMind Key, Country Rules and Feeds

pfBlockerNG GeoIP uses MaxMind country data to build IP lists for firewall policy. This guide covers the license key, country selections, inbound and outbound actions, IP reputation feeds, and checks after updates. For package installation and DNS filtering, use the pfBlockerNG setup guide.

A framing note up front: GeoIP and IP reputation operate at the packet/firewall layer, not the DNS layer. They block traffic to/from IP addresses based on the country or reputation list the IP belongs to. This is a fundamentally different control from DNSBL (which sinkholes domain names), and it’s most useful for reducing inbound attack surface on services you expose, not for protecting outbound browsing.

Step 1: Get a MaxMind GeoLite2 license key

GeoIP in pfBlockerNG relies on MaxMind’s GeoLite2 database, which requires a free license key (MaxMind moved to mandatory registration years ago — there’s no anonymous download anymore):

1. Register a free account at MaxMind and generate a GeoLite2 license key.
2. In pfSense: Firewall → pfBlockerNG → IP → MaxMind GeoIP configuration → paste the key.
3. Run an update so pfBlockerNG downloads the GeoLite2 country database. Without a valid key, GeoIP simply won’t populate.

Step 2: Decide what GeoIP actually buys you

Be clear-eyed about this before configuring it. GeoIP country blocking is coarse and easily evaded — attackers route through VPNs, compromised hosts, and cloud providers in “allowed” countries, and the GeoLite2 free database is less precise than the paid tier. So:

• Good use: dropping inbound connections to an exposed service (a VPN endpoint such as the one built in the pfSense WireGuard setup, or a self-hosted app) from countries you have no business with. It can restrict the source addresses allowed to contact that service.
• Poor use: treating “block a country” as a security strategy. It stops unsophisticated noise, not a determined attacker, and it will eventually block something legitimate (a CDN node, a traveling user, an email server).

Treat GeoIP as attack-surface reduction, not a firewall in itself.

Step 3: Configure GeoIP blocking

Firewall → pfBlockerNG → IP → GeoIP:

1. Pick a continent group or individual countries. pfBlockerNG organizes GeoLite2 into selectable groups and “Top Spammers” aggregations.
2. Set the action:
   • Deny Inbound — blocks connections from those countries to your WAN. Check the selected interfaces and generated rules: inbound describes the direction of the rule, not a guarantee that legitimate traffic is unaffected.
   • Deny Outbound — blocks your hosts from reaching those countries. Use sparingly; it breaks more than people expect (CDNs, cloud APIs, software updates served from unexpected regions).
   • Deny Both — both directions. Most aggressive; most likely to cause mystery breakage.

For a homelab, Deny Inbound on a few high-noise regions is the sane starting point — and only meaningfully helps if you actually expose services inbound. If your WAN exposes nothing, inbound geo-blocking mostly just trims firewall-log noise.

Step 4: Add IP reputation feeds

Firewall → pfBlockerNG → IP → IPv4 (and IPv6) → add feeds:

• Emerging Threats — free IP block lists of known-bad actors (compromised hosts, C2, scanners).
• Spamhaus DROP — networks Spamhaus recommends dropping entirely (hijacked allocations, known bad netblocks).
• Abuse.ch feeds (e.g., Feodo Tracker) — malware C2 infrastructure.

For each, set State ON and choose Deny Inbound (and optionally Deny Outbound for C2 lists, where blocking your hosts from reaching known C2 is genuinely valuable). IP reputation feeds are higher signal-to-noise than blanket geo-blocking because they target behaviour, not geography — prioritize a couple of reputable reputation feeds over wide country blocks.

Keep the list lean. As with DNSBL, ten overlapping mega-lists inflate the rule count, slow updates, and raise false positives without proportional benefit. A small set of reputable feeds (ET + Spamhaus DROP + one malware-C2 feed) covers the vast majority of value.

Step 5: Update and confirm the rules exist

1. Firewall → pfBlockerNG → Update → Run to download the databases and feeds; watch the log for any failed/dead feeds.
2. pfBlockerNG materializes the selections as aliases and auto-generated firewall rules. Confirm they appear: Firewall → Rules (the auto-rules carry pfBlockerNG descriptions), and Firewall → Aliases (the GeoIP/reputation tables).
3. The pfBlockerNG dashboard (Firewall → pfBlockerNG → Reports / Alerts) shows packets matched per list — use a match to identify the rule and list involved; a quiet log alone does not show that updates failed.

Verify and roll back

Verify by checking the Alerts view for blocked inbound packets attributed to a feed, and confirm legitimate outbound traffic still works (browse normally, run an update). If something legitimate breaks and you can’t immediately find the offending list, the fast rollback is to set the offending feed’s State to OFF (or the GeoIP action to a less aggressive mode) and re-run an Update — service is restored in one cycle without uninstalling anything. Keep a habit of checking the Alerts log when triaging “X stopped working at the network edge.”

When GeoIP/IP-reputation isn’t worth it

If your WAN exposes no inbound services, inbound geo-blocking is mostly cosmetic log-trimming — the firewall’s default-deny already drops unsolicited inbound. If you find yourself whitelisting constantly because a “blocked” country hosts a CDN or service you need, your country selection is too broad; narrow it or drop GeoIP in favor of targeted reputation feeds. And never let GeoIP create a false sense of security — it’s one thin layer of attack-surface reduction that complements, but never replaces, patching, strong auth, and not exposing admin panels in the first place. For payload-level inspection on the traffic that does get through, layer an IDS/IPS engine like Snort or Suricata on top — GeoIP and IP-reputation drop known-bad addresses before the signature engine has to look at them.

Comparing to OPNsense? OPNsense handles GeoIP/reputation differently (often via aliases and the GeoIP feature or Zenarmor); see firewallcompare.com for a side-by-side. The MaxMind GeoLite2 free database underpins the GeoIP feature on both platforms.

Related across the network

• What a Pi-hole DNS Sinkhole Can and Cannot Block — piholehq.com