On Wednesday 14 February 2007 12:11 pm, Darren Spruell wrote:
> 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
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 <DMZ_production_boxes> 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 <non-servers> to <Internet>
keep state
Thanks for the help.
--
Tim Kuhlman
Network Administrator
ColoradoVnet.com
