pfSenseLab
Isometric vector illustration showing firewall rules with geoip and ip reputation icons for pfBlockerNG on pfsense system.
Security

pfBlockerNG GeoIP and IP Reputation Blocking on pfSense

Go beyond DNSBL: configure pfBlockerNG's GeoIP country blocking and IP reputation feeds on pfSense — MaxMind GeoLite2 setup, inbound vs outbound actions, and why geo-blocking is not a security strategy on its own.

By pfSenseLab Editorial · · 8 min read

DNSBL ad-blocking is what most people install pfBlockerNG for, but the package’s other half — IP-layer blocking — is where it earns its keep at the WAN edge. This guide covers pfBlockerNG’s GeoIP country blocking and IP reputation feeds: how to wire them up with a MaxMind key, how the inbound/outbound actions work, and the honest limits of geo-blocking as a security control. (If you haven’t set up the DNS side yet, start with the pfBlockerNG DNSBL setup first.)

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, a self-hosted app) from countries you have no business with. It measurably cuts log noise and opportunistic scanning.
  • Poor use: treating “block China/Russia” 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 (e.g., Asia, Africa) 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. This is the safe, high-value default: it only affects unsolicited inbound and won’t break your outbound browsing.
    • 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 / EDROP — 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 — a healthy edge typically shows steady inbound hits on the reputation feeds.

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.

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

Comments