On 2/14/07, Tim Kuhlman <[EMAIL PROTECTED]> wrote:
I have pf running on an OpenBSD 4.0 (patches 1-5, 7) router and I have one user with two Gentoo Linux machines with kernel 2.6.18 who is having troubles. Everyone else is having no problem at all. This user is having any tcp connection he makes dropped by the firewall. The state shows up when I run "pfctl -ss" but a sniff on both ends of the router shows that it is dropping the packets. If I set the debug level to loud I get the following output.
[snip]
One other point I needs some clarification on, in my searching around I did find an article saying that you need the "flags S/SA" everytime you use keep state for tcp connections in your firewall rules. This didn't seem right to me but I tried it anyway just to see and it had no affect. What is the final word on this, should you always use "flags S/SA"?
This kind of thing has happened to me in the past; likely you're doing something wrong with your state building in the first place so that you're getting state built one direction one interface and checked on a different one, or similar. If you simplify your ruleset as a temporary test, you'll probably find things magically work. If so you'll know it's not the Linux boxen or firewall itself but your policy. Gradually add components back into the ruleset and you'll likely narrow down where you've b0rked it.
A couple of other points, I have tried various combinations of scrubing in my pf rules including turning it off with no luck. Also all other machines including other linux boxes work fine with this. If any more information is needed let me know. Thanks for the help!
Yeah, when I went through it scrub rules had nothing to do with it. All state, period. (Note that in -current the default is now to implicitly build rules with both 'keep state' and 'S/SA' without having to specify; default stateful behavior makes these boo-boos less likely.) When I had the same problem, it was very erratic and seemed isolated to a Linux box at first too. I don't know if there's something in the TCP stack that reacts more adversely to this, but my fix in that case was a refactoring of my state model. YMMV. DS
