[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: troubles with ipnat TCP entries
2008/5/7 Erik Bertelsen <bertelsen.erik%gmail.com@localhost>:
> 2008/5/4 Manuel Bouyer <bouyer%antioche.eu.org@localhost>:
>> I upgraded my home router to yesterday's current, and since then I have
>> troubles with ipnat: it seems to keep states for a lot of connections
>> which have been closed by either the application or the server,
>> while it closes TCP connection which are still active (e.g. an imaps
>> session initiated from mutt). FWIW, this is on a sparc (so big-endian)
>> Attached is the output of ipnat -lv on this box.
>> Notice that there's a lot of TCP map to remote host port 80 which have been
>> closed from the host or server side (a netstat on the nated host confirmes
>> this). These have a long TTL.
>> On the other hand, my connection to 184.108.40.206 port 993 (the first entry
>> the output below) has a ttl of only 465. This is the connection which is
>> dropped by the NAT box quite fast, while mutt had the connection to the
>> server still open.
>> Does anyone else have noticed this problem, or have an idea about it ?
>> Manuel Bouyer <bouyer%antioche.eu.org@localhost>
>> NetBSD: 26 ans d'experience feront toujours la difference
> Yes, for some time (at least a month) I have seen a similar behaviour:
> I have a i386-box running current functioning as my NAT gateway and
> after some time it collects a lot of NAT entries. As a user I
> typically observe this when I use gmail from a machine on my local LAN
> and the browser after a while cannot connect to the server.
> It took me some time to suspect my gateway machine and then reboot
> this machine would solve the problem for a while. Later I observed
> that when it is stuck it typically has 1500-2000+ entries in the NAT
> table and that running ipnat -F would clear it up without a reboot.
> - Erik
This seems to have been fixed even if I did not notice any commit message
targeted against this problem.
My gateway machine now runs a -current kernel 4.99.63 of 29 May and
without having to flush the NAT tables (current no. of entries < 30) it
seems to be able to keep running.
Main Index |
Thread Index |