The goal was straightforward: block overseas inbound connections to a Synology NAS with ports exposed on WAN. pfBlockerNG was installed, GeoIP was enabled, every region outside North America was configured. And yet traffic from overseas was still getting through. The firewall logs were also suspiciously quiet about it.
First thing to rule out with any pfBlockerNG GeoIP issue: the MaxMind license key. Since MaxMind locked down their free tier a few years back, if you don't have a valid Account ID and license key entered under pfBlockerNG General, the GeoIP databases never actually download. pfBlockerNG will act like everything is fine — it's just enforcing empty aliases. Verify the key is populated and that the MaxMind account shows recent download activity. In this case, the key was valid and downloads were happening. So that wasn't it.
The Real Problem: Deny Both vs. Deny Inbound
The GeoIP configuration had every foreign region set to Deny Both. Sounds thorough. It's actually the wrong setting for this use case, and it creates a subtle problem that's easy to miss.
Here's how pfSense's WAN works by default: unsolicited inbound traffic is already implicitly blocked. The firewall doesn't allow new connections in from the internet unless you have an explicit NAT rule or firewall pass rule that opens it. So pfBlockerNG GeoIP on WAN inbound is primarily relevant for traffic destined at your open ports — in this case, the NAT rule forwarding to the Synology.
Deny Both does two things: blocks inbound and blocks your LAN machines from initiating outbound connections to those countries. That second half is where the problem hides. Because pfBlockerNG generates firewall rules from the GeoIP aliases, and Deny Both applies those rules to traffic in both directions on WAN, the rule order and state table interaction can create situations where return traffic for legitimate outbound sessions gets caught — or where the rules aren't being evaluated the way you'd expect on actual inbound port-forwarded traffic.
Deny Inbound is what actually accomplishes the goal: block foreign source IPs from reaching your forwarded ports, while leaving outbound completely untouched. Your internal machines can still browse to European and Asian sites without any issue.
The Fix
In pfBlockerNG, navigate to Firewall → pfBlockerNG → IP → GeoIP. For every region you're blocking (ARIN is North America — leave that Disabled unless you want to block Canada and Mexico too):
- Change the action from Deny Both to Deny Inbound
- Enable logging on each region
- Leave North America / ARIN set to Disabled
After saving, run a Force Update under pfBlockerNG → Update to regenerate the firewall rules from the updated configuration. pfBlockerNG will rebuild its aliases and rules, and you should start seeing GeoIP hits in Status → System Logs → Firewall within minutes.
Verifying It's Actually Working
After the Force Update, check the firewall log under Status → System Logs → Firewall. Filter by the pfBlockerNG GeoIP interface. You should see blocked entries from foreign source IPs attempting to hit your forwarded ports. If the Synology has any public-facing services, you'll typically see hits within a few minutes — the internet doesn't stop poking at exposed ports.
Also verify outbound still works: from a machine on the LAN, browse to a site hosted in Europe or Asia. If Deny Inbound is set correctly, that should load fine. If it's still breaking outbound, something else is wrong with your rule configuration.
Wrapping Up
The summary: pfBlockerNG GeoIP with Deny Both seems like the safer, more complete option, but for a WAN-inbound protection use case it's the wrong tool. Deny Inbound is the correct setting if your goal is protecting exposed ports from foreign source IPs while leaving your LAN's outbound traffic unrestricted. Enable logging so you can actually confirm it's doing its job, and make sure your MaxMind key is valid or none of it matters anyway.