On Fri, 21 Aug 1998, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
>> So the real problem is that in certain situations (masqueraded
>> connections, kernels > 2.1.108), tcp.live is calculated incorrectly.
>> We should really fix that, I guess, instead of patching over it in the
>> filter rules. Not tonight, though. :-)
> Has anyone found a complete answer to this problem yet?
No, but those filter rules work for me in most cases.
> I've implemented the rules suggested...
> Rule 6: ignore tcp ip.tot_len=40,tcp.live,!tcp.fin
> Rule 13: keepup tcp 30 tcp.fin
> Rule 14: ignore tcp tcp.fin
> This only helps a little.
Post or send me your entire filter file and I'll compare it to mine.
> When a masqueraded host connects to the outside world, I get two entries in
> the diald connection queue - one from the client to the outside host, and one
> from the firewall to the outside host:
> (Firewall: 158.152.16.50, Masq client: 10.0.1.4, outside host: 131.111.217.175)
> tcp 10.0.1.4/2464 131.111.217.175/23 00:07:28
> tcp 131.111.217.175/23 158.152.16.50/61343 00:07:28
> Surely the connection from the masqueraded host (10.x.x.x) shouldn't appear in
> the connection queue at all - if diald is snooping the packets which go out
> the ISDN link then it shouldn't see anything from the private network.
I can't recall exactly what happens on mine, but yours does seem odd. You
can send me the rest of your config files and I'll take a look at them
too.
> Whatever the cause, the result is that only one of the connections is
> removed from the queue when the session ends, depending on which machine
> actually terminates the connection. If the internal machine terminates
> the connection, then the connection from the firewall to the outside
> remains in the queue, and vice versa. The link still remains up for ten
> minutes waiting for the other connection to time out.
Hmm, interesting.
Ed
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
