Nein, die Verbindung gilt erst dann als aufgebaut wenn nach dem Versenden von SYN,ACK ein ACK zur�ckgekommen ist. Da das SYN,ACK nicht durchkommt, kann auch kein ACK zur�ckkommen...
Hier irrt der Bj�rn (evtl.)
Das erste TCP-Paket hat noch kein ACK (woher auch, welches SYN sollte denn da incrementiert werden) - und das wird mit dem --state=NEW erfasst.
Das ist korrekt.
Alle anderen Pakete laufen f�r IPTables bereits als ESTABLISHED, auch wenn die eigentliche TCP-Verbindung erst nach abgeschlossenem Hin-Her-Hin endg�ltig etabliert ist.
Das ist zur H�lfte richtig. Die Verbindung gilt f�r den Initiator der Verbindung als ESTABLISHED, sobald SYN,ACK als Antwort auf SYN zur�ckgekommen ist. F�r die Gegenstelle ist sie erst dann ESTABLISHED wenn sie als Antwort auf das SYN,ACK ein SYN bekommen hat. Dieses Vereinbarung ist auch bekannt als Three-Way Handshake, RFC793.
Damit Du Dich nicht �rgerst habe ich mal eben umgestellt auf "--state NEW,ESTABLISHED,RELATED". Ohne Erfolg.
Und welche Regel blockt es (du kannst ja bei den Regeln mit entsprechenden Kommentaren Loggen)?
Bei mir heisst die Regel SHRED, der entsprechende Kommentar im log lautet ILLEGAL_PACKET (siehe meine erste Mail). Genau genommen ist SHRED eine Regel die alles ungematchte blockt.
Was hat IPSec damit zu tun?Die Frage ist also, warum kann ich mit IPsec nicht ohne weiteres auf "--state NEW" pr�fen.
Das ist Teil der Problembeschreibung. Wenn Du mir diese Frage beantworten kannst, w�re ich sicher einen Schritt weiter.
Bin ich dazu da deine Hausaufgaben zu machen? ;-)
Du mu�t es nicht tun, aber ich werde Dich nicht aufhalten. ;)
Ich vermute dass ich einen Kernelbug erwischt habe...
-- Mit freundlichen Gruessen Bjoern Schmidt
--
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)
