I'been trying to use this option on port 25 on my mail server at home, with a view to eventually trying to prevent at least some spam. The behaviour hasn't been at all what I expected, and I obviously have misunderstood something, so for now, I've got a test setup on my LAN as follows:

Server machine ("data.scotts", 192.168.0.1) has an entry in pf.conf thus:

table persist .... block in log all block out all pass in log quick on dc0 from wesley.scotts to dc0 flags S/SA keep state (max-src-conn-rate 1/30, overload )

(dc0 being the LAN interface, and wesley a test client) -- this is close to the start of the rules to make sure it's operative. There's a later pass rule anyway for known LAN clients; the logs show the rule above is the one that's hit, as expected.

On the client, wesley.scotts (192.168.0.6), I'm using 'nc' in a loop to create a continuous stream of connect requests at about 1 per second (echo -n "$x.. " | nc -o data.scotts 1234 where x is a loop counter)

I'm doing a tail on the pf log output.

By my understanding, this should cause wesley to be put into the table within 30sec or so. This doesn't happen - the table remains empty for as long as I've watched (3 minutes or more).

However, if I start a corresponding server process up (nc -l -k 1234), wesley appears fairly quickly in the table -- but I also get a lot of block entries in the log (connection, not syn packets), a lot of the connections are missed (shown by the loop counter received at the server end), and the nc program pair hangs frequently. A typical 'block' log entry would be

19:11:11.259483 rule 6/0(match): block in on dc0: 192.168.0.6.55516 > 192.168.0.1.1234: FP 0:6(6) ack 1 win 33304

This shows a match against the default-to-block rule (rule 6) - so something strange has happened to the 'keep state' operation.

This behaviour isn't at all what I expected to see.

First question then is why does the behaviour of pf depend on whether or not a server process is listening? Surely it shouldn't, and I've seen no mention in the documentation of this.

Second question is why does pf seemingly not notice repeated connect requests when there's no server listening?

Third question is why is pf blocking anything at all anyway with this rule?

Oh yes, this is FreeBSD 6.1-RELEASE btw.

Can anyone help me understand what's happening please? Thanks in advance for any pointers.

And thanks too for reading this far :-)