[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ipf 'keep state' and premature closedowns or missed matches



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been experimenting with ip-filter and keeping state on connections.
I've discovered an annoying problem that results in intermittently failing
file transfers (DNS zone transfers, http page downloads, plus rsync directory
mirroring via ssh) and DNS lookups.  The transfers sometimes die prematurely,
and the lookups fail, when ipf apparently mistakenly nukes a few replies (TCP
ACKS or just UDP replies).

It may be that the ip-filter state table is prematurely dis-remembering some
saved states before the connections are actually closed down.  Or it may be
that the state table is just not matching some legitimate packets.  I suspect
it's not a missed state setup in the first place, as many return packets are
accepted in the TCP cases before some are missed and fall through to a block
rule.

Anyone else trying 'keep state' on 2.5 and having similar problems?  I
haven't been able to find anthing on the topic on the ip-filter mailing list
archive.

Any ideas of where else to look, or suggestions on how to work around the
problem?  Keeping state the way I'm trying it might not be ready for prime
time yet?


Richard

- -------

Here's an example on an i386 machine running the 19990918 snapshot.  I've
also seen similar behavior on others running the 19990831 snapshot.

Log of packets dropped, improperly, causing the connections to fail (first an
incoming http session punt, then a pair of outgoing zone transfer oopses):

Sep 23 19:26:23 animas ipmon[2810]: 19:26:23.159387 [unrelated entry]
Sep 23 22:06:36 animas ipmon[2810]: 22:06:35.335563             fxp0 @0:49 b
206.168.172.17,1103 -> 206.168.227.248,80 PR tcp len 20 40 -A
Sep 23 22:06:39 animas ipmon[2810]: 22:06:38.215067             fxp0 @0:49 b
206.168.172.17,1103 -> 206.168.227.248,80 PR tcp len 20 40 -A
Sep 23 22:06:39 animas ipmon[2810]: 22:06:38.333503             fxp0 @0:49 b
206.168.172.17,1103 -> 206.168.227.248,80 PR tcp len 20 445 -AP
Sep 23 22:06:40 animas ipmon[2810]: 22:06:39.931834             fxp0 @0:49 b
206.168.172.17,1103 -> 206.168.227.248,80 PR tcp len 20 40 -A
Sep 23 22:06:40 animas ipmon[2810]: 22:06:39.949184             fxp0 @0:49 b
206.168.172.17,1103 -> 206.168.227.248,80 PR tcp len 20 40 -A
Sep 23 22:06:40 animas ipmon[2810]: 22:06:40.132096             fxp0 @0:49 b
206.168.172.17,1103 -> 206.168.227.248,80 PR tcp len 20 40 -AF
Sep 23 22:14:54 animas ipmon[2810]: 22:14:53.232439 [unrelated entry]
...
Sep 23 22:14:54 animas ipmon[2810]: 22:14:53.232439 [unrelated entry]
Sep 23 22:56:17 animas ipmon[2810]: 22:56:17.513281             fxp0 @0:49 b
207.108.70.101,53 -> 206.168.227.246,16140 PR tcp len 20 552 -A
Sep 23 22:56:17 animas ipmon[2810]: 22:56:17.515361             fxp0 @0:49 b
207.108.70.101,53 -> 206.168.227.246,16140 PR tcp len 20 552 -A

Sep 24 00:17:26 animas ipmon[2810]: 00:17:25.627259             fxp0 @0:49 b
207.108.70.101,53 -> 206.168.227.246,42088 PR tcp len 20 552 -A
Sep 24 00:17:26 animas ipmon[2810]: 00:17:25.628571             fxp0 @0:49 b
207.108.70.101,53 -> 206.168.227.246,42088 PR tcp len 20 552 -A
Sep 24 02:20:52 animas ipmon[2810]: 02:20:52.053316 [unrelated entry]

[my host was able to get the zone the next time it tried]


The relevant ipf rules are (most 0-hit rules snipped for brevity of post):

% ipfstat -ihn
0 @1 block in log quick on fxp0 proto icmp from any to any icmp-type redir
0 @2 block in log quick on fxp0 proto tcp/udp from any to any with short
5951 @3 pass in quick on fxp0 from 206.168.227.0/24 to 206.168.227.255/32
...
23 @27 pass in quick on fxp0 proto tcp from any to 206.168.227.246/32 port =
22 flags S/SA keep state keep frags
...
1644 @29 pass in quick on fxp0 proto tcp from any to 206.168.227.246/32 port
= 53 flags S/SA keep state keep frags
...
17 @38 pass in quick on fxp0 proto tcp from any to 206.168.227.248/32 port =
80 flags S/SA keep state keep frags
...
28186 @40 pass in quick on fxp0 proto udp from any to 206.168.227.246/32 port
= 53
448 @41 pass in quick on fxp0 proto udp from any to 206.168.227.246/32 port =
123
...
528 @45 pass in quick on fxp0 proto icmp from any to 206.168.227.246/32
icmp-type unreach
9 @46 pass in quick on fxp0 proto icmp from any to 206.168.227.246/32
icmp-type timex
...
1 @48 block return-rst in quick on fxp0 proto tcp from any to any port = 113
13 @49 block return-rst in log quick on fxp0 proto tcp from any to any
1 @50 block return-icmp in log quick on fxp0 proto udp from any to any
25 @51 block in log quick on fxp0 proto icmp from any to any
194 @52 pass in quick on lo0 from any to any
0 @53 block in from any to any

% ipfstat -ohn  [in /etc/ipf.rules, these are listed between what become #s
47 and 48 in the input rules above]
...
28282 @2 pass out quick on fxp0 proto tcp/udp from 206.168.227.246/32 to any
keep state
2663 @3 pass out quick on fxp0 proto icmp from 206.168.227.246/32 to any keep
state
194 @4 pass out quick on lo0 from any to any
6 @5 block out from any to any


And ipfstat says no limits hit (flood pinging will peg the maximum table
size, so I tend to believe this info):

% ipfstat -s
IP states added:
        565 TCP
        27456 UDP
        0 ICMP
        785837 hits
        67608 misses
        0 maximum
        0 no memory
        83 active
        27377 expired
        561 closed
...

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.1
Comment: www.europarl.eu.int/dg4/stoa/en/publi/166499/execsum.htm

iQA/AwUBN+vgGWKSuJuuNAZUEQKBZQCdFwEKNEiWg+iay7dddCzzeGIK4ysAoM8b
wKcP9OFaFqvOGPZV28HzuN1w
=6VQr
-----END PGP SIGNATURE-----