While it is "safe" to have a static table of just RFC-1918 space, if you want to blackhole the entire "bogon" network space, more care is needed, as ARIN will occasionally allocate addresses out of historically invalid address ranges. One way to play it safe is to use a cron job to automatically download the updated 'bogon' list and populate a table.

While it is "safe" to have a static table of just RFC-1918 space, if you want to blackhole the entire "bogon" network space, more care is needed, as ARIN will occasionally allocate addresses out of historically invalid address ranges. One way to play it safe is to use a cron job to automatically download the updated 'bogon' list and populate a table.

I've set up a table containing bogons. However, I can no longer use ssh to access the server.

My LAN is configured for a 192.168.0.0/24 range, which is not on the bogon list. I thought pf would filter by subnet with the 192.168.0.0/16 range being listed. (I have a pass quick rule to allow in 192.168.0.0/24)

There are two places where a bogon list is usefull.
First, you want to drop all packets arriving at your network stating bogus source addresses.
Secondly, you might like to drop packets that state bogus source addresses, produced by missconfigured hosts on your network, or by a failure of NAT.
The first is done by the simple rules that I stated above. the second would be a similar rule (block quick out on $ext_if from <bogons>

The other, more compex rules are interesting - They verify that the packets are good, and then flag them so they quickly pass on the way out of the internal interface.

Edit: the reason for specifying the external interface is that the local, private network needs to contact the server, and the private netspaces are on the bogon lists. There are ways to block bogons on the internal interface (Use a rule to flag valid local packets, then add an exception to your bogon filter), but it is not really worth it.

(What this message really says is, "Uh, What you say??")

__________________The only dumb question is a question not asked.
The only dumb answer is an answer not given.

, I can no longer manage my server from within the LAN (ssh is blocked), same result as the rule without naming $ext_if.

So, what I'd like is the protection of banning bogons from the outside internet, but leave my server free for ssh internally on the LAN (because I don't have a console) -- I don't want to remove the 192.168.*.* entry as any kind of 'fix', but I'm stumped here.

Bogon filtering is used on the external interface to keep bogus packets out of your network.

One wonders why bogon filtering is needed on a box that has no direct connection - this should be done on your router - but, if you do, then you will, of course, need an exception for your local networks. I don't do enough of this to feel confident about writing out a ruleset, but, first, use $loopback (or just lo0 - everyone knows what the loopback is) for the loopback, and anything other than ext_if for the other interface, so you don't confuse us.
Something like

Code:

local=192.168.1.1/24
pass on $interface from $local tag LOCAL
block quick on $interface from <bogons> not tagged LOCAL

I have no idea if that would work, but it should give you a start for troubleshooting.

__________________The only dumb question is a question not asked.
The only dumb answer is an answer not given.

I have no idea if that would work, but it should give you a start for troubleshooting.

Thanks, my fault here though. I did not explain that PF is 'self-protecting' my server behind a router (off-the-shelf hardware not running OpenBSD). The router blocks all incoming traffic by default now except for my www ports. So in my setup, int_if is actually the loopback device only, whereas ext_if is what faces the router.

My initial worry was that any open port, even forwarded, could be a 'portal' for bogons to exploit.