On Wednesday 14 February 2007 12:11 pm, Darren Spruell wrote:

quoted text
> On 2/14/07, Tim Kuhlman  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

You think it is an issue with my state table rules even though running an "pfctl -ss" shows that the state is established? 
I keep state on my outgoing connection and don't do any on the incoming connection except for some ssh connections which I rate limit. These ssh connections haven't been the issue anyway. 
The basic outgoing rule is relatively simple it is

pass out on { $int_if $vpn_if $ext_if $dsl_if $DMZ_production_if $DMZ_proto_if } proto {tcp udp icmp} modulate state
After that I do some queuing but most of the test connections should have just gone into the default queue. Here are the rules,
pass out on $ext_if proto udp from $ext_ip port $vpn_port to $vpn_tungsten keep state queue vpn

pass out on $ext_if proto udp from $ext_ip port domain to any keep state queue vpn

pass out on $ext_if from  to any modulate state queue dmz
The problem has occurred between pretty much any combination of those interfaces except the ext_if and dsl_if which I haven't tested. I will try and simplify things a bit but unfortunately the box is in production and has a lot of traffic moving through it right now so I can't do anything too drastic right away. One thing I will do right away is add the flag S/SA to all of these entries, I don't see any reason why that will break anything on the live machine.
Any other specific suggestions?
Whoops I was just grepping for state in my rules and I missed one though it shouldn't have applied to any of these connections

pass in on $int_if route-to ($dsl_if $dsl_gw) from  to  keep state
Thanks for the help.
--

Tim Kuhlman

Network Administrator

ColoradoVnet.com