(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 <[EMAIL PROTECTED]>: > > >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 [EMAIL PROTECTED] > > > -- > Haeufig gestellte Fragen und Antworten (FAQ): > http://www.de.debian.org/debian-user-german-FAQ/ > > Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] > mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl) > >
