WORKAROUND: Firewall/NAT TCP timeouts (Debian Kernel 2.4.26)
(mit Absicht auch an PM, da Thread scho netwas älter!)
Danke Harald,
für deine Hinweise. Es scheint tatsächlich der Router zu sein. Nachdem ich mit
Hansenet gesprochen habe wurde ein (OT) 'vielversprechendes Firmwarepdate'
auf den Router aufgespielt. Seitdem sind wenigstens die 'Portblockaden' nicht
mehr aufgetreten. Auf weiteres Nachhaken bzgl. Timeouts wurden folgende
Routereinträge offenbart:
ICMP Idle Timeout 1min
UDP Idle Timeout 5min
TCP Idle Timeout 2min
TCP Negotiation Timeout 2min
Other Idle Timeouts 1min
Den TCP Idle Timeout ließ ich erhöhen auf 20min (ACHTUNG für Nachahmer: die
eigene Firewall sollte dann nicht mehr DROPpen sonder REJECTen - sonst kann
ein Portscan schon ein Überlaufen der NAT Tabelle im Router hervorrufen
(Klassischer DoS Angriff)).
Leider hat das nichts gebracht. Ein jetzt von mir eingeführte 'Keepalive'
mittels einer Dummymessage alle 10s hält die Verbindungen tatsächlich aktiv.
Bei 30s wirds schon wieder wackelig. Nächste Woche wird der Router
vorsichtshalber von Hansenet getauscht...
Mfg, Tim
Am Freitag, 9. Juli 2004 00:39 schrieb Harald Weidner:
> Hallo,
>
> Tim Ruehsen <tim.ruehsen@gmx.de>:
>
> >ich habe hier Probleme mit NATed TCP/IP Verbindungen von 'draussen'.
> >Allerdings nur, wenn die Verbindung längere Zeit stehen bleibt und kein
> >Traffic für ca. 1-2 Minuten erfolgt. Wenn dann der 'interne' Server ein
> >Packet schickt, kommt sofort ein Antwortpacket mit 'RST' Flag gesetzt - die
> >Verbindung wird dann geschlossen. Der Client bekommt überhaupt nichts mit -
> >das Packet kommt also nicht von ihm sondern von der Firewall/NAT Modul.
>
> Das ist kein übliches Verhalten des Linux NAT Codes. Hier liegt irgend
> ein Problem vor.
>
> >Es muß noch gesagt werden, daß vor meiner Firewall noch ein Router mit NAT
> >sitzt (SpeedTouch 600series). Das Problem könnte also auch dort liegen.
>
> Ich würde als erstes vermuten, dass nicht der Linux-Kernel, sondern
> der Router die RST Pakete erzeugt. Hast Du das schon verifiziert?
>
> Kann es sein, dass der Router Dial-on-Demand macht und nach
> zweiminütiger Inaktivität eine neue IP-Nummer erhält? In diesem
> Fall wären die Verbindungen über die alte IP-Nummer hinfällig.
>
> >- Ist dieses Problem jemandem bekannt? Falls ja, ist es Router oder
> >Linux-Firewall? Und wie läßt es sich 'richtig' beheben?
>
> Wie gesagt, es ist kein normales Verhalten. Im Gegenteil, wenn Du es
> nicht explizit verhinderst, dann überleben TCP-Verbindungen durch
> eine iptables-basierte Firewall hindurch sogar einen Reboot des
> Firewall-Rechners.
>
> Wenn Du sicher bist, dass der Linux-Firewall schuld ist, dann solltest
> Du mal die iptables-Regel schicken, dann kann man vielleicht mehr dazu
> sagen.
>
> >- Wie lasse ich mir die diesbezüglichen Timeouts von iptables (NAT)
anzeigen?
> >(Setzen geht angeblich nicht - früher mit ipchains ging es).
>
> Du kannst mit "cat /proc/net/ip_conntrack" alle aktiven TCP Verbindungen
> anzeigen lassen. Ein fixes Timeout gibt es nicht; das wird dynamisch
> in Abhängigkeit von der Größe der Verbindungstabelle geregelt.
>
> Gruß, Harald
>
> --
> Harald Weidner hweidner@gmx.net
>
>
> --
> Haeufig gestellte Fragen und Antworten (FAQ):
> http://www.de.debian.org/debian-user-german-FAQ/
>
> Zum AUSTRAGEN schicken Sie eine Mail an
debian-user-german-REQUEST@lists.debian.org
> mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org
(engl)
>
>
Reply to: