IPfilter changes?

[Martin Stiemerling]

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 at ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de