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)
