Solved pf tables and nat

[BostonDriver]

In an attempt to keep grades from getting even worse than they are, I'm trying to get pf(4) to keep a PC "focused" until homework is finished. I use tables to help with ssh brute force attacks and thought using tables would work for this problem. I can't get it to work. I'm curious if NAT has anything to do with it.

When homework should be done, I add typical time sink sites to the <finishhomework> table via ptctl(8) manually. I only want this one PC to have traffic blocked however, not every device behind NAT.

The rules look like:

table <bruteforce> persist
table <finishhomework> persist

nat on $ext_if inet from 172.16.8.0/24 to any -> ($ext_if)

block drop log quick from <bruteforce>

block in log quick on $int_if from 172.16.8.44 to <finishhomework>
block out log quick on $int_if from <finishhomework> to 172.16.8.44
block in log quick on $ext_if from <finishhomework> to 172.16.8.44
block out log quick on $ext_if from 172.16.8.44 to <finishhomework>

Packets are not dropped, and the counters for bytes, packets, state are always zero according to pfctl -vvv -s rules.

The rule evaluations counter does increase.

There probably only needs to be one rule, but since that didn't work I tried the others.

Am I missing something?

Thanks

 

[junovitch@]

One little thing to keep in mind is connections that already have a state do not result in a ruleset evaluation. Connections already open to the sites will continue to work unless you kill the states with pfctl -k <host>. See pfctl(8) for details on that.

After that, I don't see anything that looks wrong. Although you should be fine only caring about $int_if to prevent new state entries from being created. If you kill existing states when you add them to the connection then nothing will ever match on your external interface. What does pfctl -t finishhomework -T show look like when you have entries and what do those rules look like after they are parsed (show pfctl -vs rules for those rules).

 

[BostonDriver]

Thanks for the hint re pfctl -k <host>

I found the issue. I had an unfiltered macro listing interfaces, and match on it early.

pass quick on $unfiltered

$int_if was in there and shouldn't have been

pilot error