Date: Tue, 22 Apr 2003 11:18:35 +0200 From: Martin Stiemerling <Martin.Stiemerling@ccrle.nec.de> To: Daniel Lang <dl@leo.org> Cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? Message-ID: <3EA508EB.5020906@ccrle.nec.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Daniel, the stuff below looks ok so far, i.e. it should work. Perhaps you can check with 'ipfstat -hio' (it shows the hit counts per rule) where the intial TCP packet from your host 131.159.72.12 is matched against a rule, especially this rule: > pass in quick from 131.159.72.12/32 to any If this doesn't help try to replace the state rule with this and check whether this rule has been hit at all. > pass out quick proto tcp/udp from any to any keep state keep frags NEW > pass out quick proto tcp from any to any flags S keep state keep frags IP Filter has neither changed rule processing nor a new keyword. Cheers Martin Daniel Lang wrote: > Hi Folks, > > I've investigated further and come to the conclusion, that > the ipfilter on my box does no longer keep the state all. > It doesn't work any more for both TCP und UDP. > > I tried to initiate a ssh connection to a host, that is > not explicitly permitted, and I can see that its replies > are blocked by ipfilter: > [..] > Apr 22 10:11:22 atleo3 ipmon[60]: 10:11:21.773527 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:28 atleo3 ipmon[60]: 10:11:27.973741 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:29 atleo3 ipmon[60]: 10:11:29.593264 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN > Apr 22 10:11:40 atleo3 ipmon[60]: 10:11:40.174349 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:56 atleo3 ipmon[60]: 10:11:56.593091 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN > Apr 22 10:12:04 atleo3 ipmon[60]: 10:12:04.374875 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > [..] > > Maybe the ruleset processing order has changed? Here are relevant > rules, as used in the kernel. I use ipfstat -oi to show you my rules: > [..] > > pass out quick on lo0 from any to any > pass out quick proto icmp from any to any > pass out quick proto tcp/udp from any to any keep state keep frags > > block in from any to any > pass in quick on lo0 from any to any > pass in quick from 131.159.72.12/32 to any > block in quick proto tcp from any to any with short > block in log level local7.notice from any to any > block in log level local7.notice proto tcp from any to any > ^^^^^^^^^^^^^^^^^^^ > This is the rule, that blocks the packet according to the log (@7). > [..] > block return-rst in log level local7.notice quick proto tcp from any to any port = 1080 > block return-rst in log level local7.notice quick proto tcp from any to any port = 3128 > block return-rst in log level local7.notice quick proto tcp from any to any port = 8080 > block in proto udp from any to any > pass in quick proto icmp from any to any > block in quick from any to 224.0.0.0/8 > [ rules with special host exceptions omitted ] > > Maybe there is now a special keyword required to make a states > overrule blocking rules? > > If I display current state in 'top' mode, and try to initiate a > connection, the state does not get added! Only states of connections, > that can be established due to explicitly allowed rules seem to get added. > > So that seems to be the problem, that somehow a connection is only > added to the state tables, once it is established? That would > explain why it breaks now, but I'm not sure, if I'm just doing something > wrong? > > Any explanations appreciated. > > Best regards, > Daniel -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA508EB.5020906>