On Sun, 23 Nov 2014 13:22:01 -0500 "D'Arcy J.M. Cain" <[email protected]> wrote: > To summarize, the answer to my original issue is to NOT keep state on > incoming UDP connections.
After making this change the situation seems to have improved but it is still not quite right. Here is the relevant parts of my pf.conf. table <AUTOBLOCK> persist set block-policy drop scrub in all block in log on $ext_if pass out all block in quick log on $ext_if from <AUTOBLOCK> pass in log on $ext_if proto udp from any to any port 5060 no state The last two lines are rules 8 and 13. This morning I saw three connections from 75.55.69.69 ports to 5060: 2014-11-28 04:32:59.283909 rule 13/0(match): pass in on bge0: 75.55.69.69.6216 > 98.158.139.74.5060: SIP, length: 404 2014-11-28 04:33:08.144545 rule 13/0(match): pass in on bge0: 75.55.69.69.5770 > 98.158.139.74.5060: SIP, length: 425 2014-11-28 04:33:14.645817 rule 13/0(match): pass in on bge0: 75.55.69.69.6150 > 98.158.139.74.5060: SIP, length: 415 Then nothing in the pflog until; 2014-11-28 04:38:54.841506 rule 8/0(match): block in on bge0: 75.55.69.69.5816 > 98.158.139.74.5060: SIP, length: 351 That address was added to the AUTOBLOCK table at Nov 28 04:34:00 EST 2014. Between that time and the time it actually blocked the address at 2014-11-28 04:38:54 there were over 8000 connections. It looks like it took almost five minutes before the block started working. Is this a timeout in pf before it re-reads internal tables? Can I get around that? Can I at least lower the timeout? Cheers. -- D'Arcy J.M. Cain <[email protected]> http://www.NetBSD.org/ IM:[email protected]
