TCPMSS-Firewallregel greift nicht
Hallo SuSE-ISDN-Experten, ich habe aufgrund des MSS- bzw. MTU-Problems bei DSL-Verbindungen über IP- Masquerading folgende bekannte FORWARD-Firewallregel eingetragen: # iptables -I FORWARD -i eth0 -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Eigenartigerweise werden Pakete, die diese Bedingung erfüllen, nicht ACCEPTed, sondern am Ende der FORWARD-Regelliste geloggt (mit der entsprechenden LOG-Regel). Wenn ich statt dessen folgende Regel eintrage, gehen natürlich nicht alle Seiten. # iptables -I FORWARD -i eth0 -o ppp0 -j ACCEPT Wenn ich alle Clients auf eine MTU=1492 stelle, funktioniert alles. Das passt mir aber nicht, und ich möchte wissen, warum die Regel nicht greift. Ich kann nicht gewährleisten das alle Clients eine MTU von 1492 benutzen. Folgendes Kommando listet in der FORWARD-Liste: # iptables -L -nv pkts bytes target prot opt in out source destination . . 0 0 TCPMSS tcp -- eth0 ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU . . 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `BLOCKED_FORWARD: ' Im Falle der gesetzten TCPMSS-Regel werden diese Pakete geblockt: # tail -f /var/log/messages Jun 21 14:52:02 dslserver kernel: BLOCKED_FORWARD: IN=eth0 OUT=ppp0 SRC=192.168.1.10 DST=???.???.???.??? LEN=44 TOS=0x00 PREC=0x00 TTL=127 ID=7680 DF PROTO=TCP SPT=1032 DPT=110 WINDOW=11680 RES=0x00 SYN URGP=0 Ich bitte Euch, mir keine langen "Romane" oder Links über MSS zuzuschicken. Der Hintergrund ist mir bekannt. Ich möchte wissen warum diese Regel nicht geNATtete Pakete durchläßt. Achso: ich benutze eine Fritz!DSL. Vielen Dank im Voraus. Gruß - Robert
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 28 June 2003 00:17, Robert Gött wrote:
Hallo SuSE-ISDN-Experten,
ich habe aufgrund des MSS- bzw. MTU-Problems bei DSL-Verbindungen über IP- Masquerading folgende bekannte FORWARD-Firewallregel eingetragen: # iptables -I FORWARD -i eth0 -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
. . 0 0 TCPMSS tcp -- eth0 ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Die ersten 2 Nullen bedeuten, dass keine Pakete diese Regel benutzt haben. Bei mir ist das die erste Regel in der FORWARD chain: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 314 18092 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Vielleicht lässt Du mal -i und -o weg. Ansonsten sind Deine und meine Regel gleich. Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/caRwicyCTir8T4RAnY0AJ9N9WNcgukeU+gF8VBCwB+qtPlX7gCeIO+f abkMwBAFSHl4QpwSw9IUe5g= =jv8d -----END PGP SIGNATURE-----
Ich verstehe das nicht. Warum sind die Anzahl der Packete, die die LOG- Regel passiert, genauso hoch wie die der TCPMSS-Regel? Nach Deinem Änderungsvorschlag habe ich folgende Ergebnisse: FORWARD-Regeln # iptables -L -vn ... Chain FORWARD (policy DROP 32 packets, 1408 bytes) pkts bytes target prot opt in out source destination 32 1408 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 0 0 ACCEPT all -- ppp0 eth0 0.0.0.0/0 192.168.175.0/24 state RELATED,ESTABLISHED 0 0 invalid all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 xmas_scan tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x3F 0 0 null_scan tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00 0 0 spoofing all -- eth0 * !192.168.0.0/24 0.0.0.0/0 0 0 spoofing all -- ppp0 * 192.168.0.0/16 0.0.0.0/0 0 0 spoofing all -- ppp0 * 172.16.0.0/12 0.0.0.0/0 0 0 spoofing all -- ppp0 * 10.0.0.0/8 0.0.0.0/0 32 1408 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `BLOCKED_F: ' ... # tail -f /var/log/messages ... Jun 30 19:44:02 dslserver kernel: BLOCKED_F: IN=eth0 OUT=ppp0 SRC=192.168.0.10 DST=207.68.185.58 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=3842 DF PROTO=TCP SPT=1056 DPT=80 WINDOW=60352 RES=0x00 SYN URGP=0 ... Gruß - Robert Torsten Foertsch schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 28 June 2003 00:17, Robert Gött wrote:
Hallo SuSE-ISDN-Experten,
ich habe aufgrund des MSS- bzw. MTU-Problems bei DSL-Verbindungen über IP- Masquerading folgende bekannte FORWARD-Firewallregel eingetragen: # iptables -I FORWARD -i eth0 -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
. . 0 0 TCPMSS tcp -- eth0 ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Die ersten 2 Nullen bedeuten, dass keine Pakete diese Regel benutzt haben.
Bei mir ist das die erste Regel in der FORWARD chain:
Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 314 18092 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Vielleicht lässt Du mal -i und -o weg. Ansonsten sind Deine und meine Regel gleich.
Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+/caRwicyCTir8T4RAnY0AJ9N9WNcgukeU+gF8VBCwB+qtPlX7gCeIO+f abkMwBAFSHl4QpwSw9IUe5g= =jv8d -----END PGP SIGNATURE-----
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
Robert Gött wrote:
FORWARD-Regeln # iptables -L -vn ... Chain FORWARD (policy DROP 32 packets, 1408 bytes) pkts bytes target prot opt in out source destination 32 1408 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 0 0 ACCEPT all -- ppp0 eth0 0.0.0.0/0 192.168.175.0/24 state RELATED,ESTABLISHED 32 1408 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 ...
# tail -f /var/log/messages ... Jun 30 19:44:02 dslserver kernel: BLOCKED_F: IN=eth0 OUT=ppp0 SRC=192.168.0.10 DST=207.68.185.58 LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=3842 DF PROTO=TCP SPT=1056 DPT=80 WINDOW=60352 RES=0x00 SYN URGP=0
--state NEW vergessen? Was soll denn ausgehend erlaubt sein? Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 30 June 2003 21:31, Robert Gött wrote:
Ich verstehe das nicht. Warum sind die Anzahl der Packete, die die LOG- Regel passiert, genauso hoch wie die der TCPMSS-Regel? Nach Deinem Änderungsvorschlag habe ich folgende Ergebnisse:
FORWARD-Regeln # iptables -L -vn ... Chain FORWARD (policy DROP 32 packets, 1408 bytes) pkts bytes target prot opt in out source destination 32 1408 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 0 0 ACCEPT all -- ppp0 eth0 0.0.0.0/0 192.168.175.0/24 state RELATED,ESTABLISHED
Ich denke, die Regel in der Zeile über dieser greift nicht. Ich weiss nicht genau, wann die Ziel-Adress-Umsetzung gemacht wird, aber probier mal 192.168.175.0/24 wegzulassen. Ich schicke Dir mal mein firewall-Script mit. Du kannst es mit fake=echo ./firewall.sh aufrufen. Dann schreibt es vor jeden iptables Befehl ein echo. Sinn des Ganzen ist ungefähr folgender. Ich habe eine Reihe interner Interfaces (vertrauenswürdig) und eine Reihe externer. Als erstes wird mit den built-in chains INPUT, OUTPUT und FORWARD festgestellt, woher ein Paket kommt. Dann wird es entweder an das Tripel (input_int, output_int, forward_int) oder (input_ext, output_ext, forward_ext), je nachdem worum es sich handelt, weitergeleitet. Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/AUACwicyCTir8T4RArhiAJ99rTgDiW5swnJ+Bo1FJyPsSAcu5wCgi0JJ 6P7unxPQaAiOdjl+nYyy2cc= =ZB/J -----END PGP SIGNATURE-----
Hallo Linux-Freunde, ich habe jetzt die Lösung für mein Problem gefunden. Die besagte Regel allein funktioniert nur, wenn die Policy der FORWARD-Chain auf ACCEPTed gestellt ist. # iptables -t filter -A FORWARD -i eth0 -o ppp0 -j TCPMSS --clamp-mss-to-pmtu -p tcp --tcp-flags SYN,RST SYN Sofern die Policy z.B. auf DROPped steht (iptables -P FORWARD DROP), ist diese Regel völlig wirkungslos. Zuerst würde der Verbindungsaufbau manipuliert, indem die für die Verbindung vereinbarte MTU auf 1492 gesetzt wird. Diese Regel akzeptiert aber noch lange nicht das veränderte Paket, und würde am Ende der Chain verworfen werden. Um das zu verhindern, ist eine zusätzliche Regel notwendig: # iptables -t filter -A FORWARD -i eth0 -o ppp0 -j ACCEPT Diese Regel muß aus besagtem Grund unbedingt hinter der TCPMSS-Regel folgen, niemals davor. Was mich wundert: Warum hatte noch niemand diese Problem gehabt? Gruß - Robert Torsten Foertsch schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 30 June 2003 21:31, Robert Gött wrote:
Ich verstehe das nicht. Warum sind die Anzahl der Packete, die die LOG- Regel passiert, genauso hoch wie die der TCPMSS-Regel? Nach Deinem Änderungsvorschlag habe ich folgende Ergebnisse:
FORWARD-Regeln # iptables -L -vn ... Chain FORWARD (policy DROP 32 packets, 1408 bytes) pkts bytes target prot opt in out source destination 32 1408 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 0 0 ACCEPT all -- ppp0 eth0 0.0.0.0/0 192.168.175.0/24 state RELATED,ESTABLISHED
Ich denke, die Regel in der Zeile über dieser greift nicht. Ich weiss nicht genau, wann die Ziel-Adress-Umsetzung gemacht wird, aber probier mal 192.168.175.0/24 wegzulassen.
Ich schicke Dir mal mein firewall-Script mit. Du kannst es mit
fake=echo ./firewall.sh
aufrufen. Dann schreibt es vor jeden iptables Befehl ein echo.
Sinn des Ganzen ist ungefähr folgender. Ich habe eine Reihe interner Interfaces (vertrauenswürdig) und eine Reihe externer. Als erstes wird mit den built-in chains INPUT, OUTPUT und FORWARD festgestellt, woher ein Paket kommt. Dann wird es entweder an das Tripel (input_int, output_int, forward_int) oder (input_ext, output_ext, forward_ext), je nachdem worum es sich handelt, weitergeleitet.
Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/AUACwicyCTir8T4RArhiAJ99rTgDiW5swnJ+Bo1FJyPsSAcu5wCgi0JJ 6P7unxPQaAiOdjl+nYyy2cc= =ZB/J -----END PGP SIGNATURE-----
--------------------------------------------------------------------------- Name: firewall.sh firewall.sh Type: Bourne Shell Program (application/x-sh) Encoding: 7bit
--------------------------------------------------------------------------- -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
participants (3)
-
Peter Wiersig -
Robert Gött -
Torsten Foertsch