ICMP-Echo-Paket werden verworfen

[Jens Tautenhahn]

Hallo,

folgendes Problem ist mit unserem Intranator aufgefallen: bei einem Traceroute aus dem internen Netzwerk nach extern wird jedes 3. ICMP-Echo-Paket mit TTL=1 vom Intranator verworfen.

Ein Traceroute (mit ICMP) aus dem internen Netzwerk bringt als erstes immer den Intranator (da Default-Gateway) und bei den Zeiten immer ein Paket, welches nicht beantwortet wurde.

Ich habe die Technik von Traceroute nachgestellt (ICMP-Echos mit größer werdender TTL) und siehe da, jedes 3. ICMP-Echo-Paket wird verworfen:

$ ping -t 1 84.148.79.133
PING 84.148.79.133 (84.148.79.133) 56(84) bytes of data.
From 192.168.0.7 icmp_seq=1 Time to live exceeded
From 192.168.0.7 icmp_seq=2 Time to live exceeded
From 192.168.0.7 icmp_seq=4 Time to live exceeded
From 192.168.0.7 icmp_seq=5 Time to live exceeded
From 192.168.0.7 icmp_seq=7 Time to live exceeded
From 192.168.0.7 icmp_seq=8 Time to live exceeded
From 192.168.0.7 icmp_seq=10 Time to live exceeded
From 192.168.0.7 icmp_seq=11 Time to live exceeded
From 192.168.0.7 icmp_seq=13 Time to live exceeded
From 192.168.0.7 icmp_seq=14 Time to live exceeded
From 192.168.0.7 icmp_seq=16 Time to live exceeded
From 192.168.0.7 icmp_seq=17 Time to live exceeded
From 192.168.0.7 icmp_seq=19 Time to live exceeded
From 192.168.0.7 icmp_seq=20 Time to live exceeded
From 192.168.0.7 icmp_seq=22 Time to live exceeded

Ein "limit" für diese Pakete konnte ich in den Firewall-Regeln nicht erkennen.

Gruß
Jens

[Gerd von Egidy]

Hallo,

wenn die TTL des abgehenden Pakets von Ihrem Rechner 1 ist, muss es der nächste Host (in diesem Fall der Intranator) verwerfen. Wenn Ihr Ziel 3 Hops entfernt ist und Sie mit aufsteigenden TTLs arbeiten, ist das genau das, was passieren soll - ohne die ICMP TIME_EXCEEDED Nachrichten kann das traceroute ja nicht die einzelnen Hops identifizieren.

Soweit ich weiß arbeitet traceroute normalerweise mit UDP und nicht mit ICMP.

Herzliche Grüße,

v. Egidy

[Jens Tautenhahn]

wenn die TTL des abgehenden Pakets von Ihrem Rechner 1 ist, muss es der nächste Host (in diesem Fall der Intranator) verwerfen.

Ist schon OK, daß das Paket verworfen wird. Aber es muß immer ein ICMP TIME_EXCEEDED zurückkommen, damit der Absender weis, daß sein Paket verworfen wurde. Wie Sie schon sagten, genau nach diesem Schema funktioniert Traceroute.

Wenn Sie sich noch einmal aus meinem Ursprungsposting die Sequenznummern ansehen, wird klar was ich meine. Auf jedes 3. Paket kommt kein ICMP TIME_EXCEEDED.

Soweit ich weiß arbeitet traceroute normalerweise mit UDP und nicht mit ICMP.

Stimmt. Das Verhalten vom Intranator ist, wie hier getestet, bei traceroute mit UDP oder ICMP das Gleiche.

Traceroute mit UDP:

$ traceroute 84.148.79.133
traceroute to 84.148.79.133 (84.148.79.133), 30 hops max, 38 byte packets
1 intranator (192.168.0.7) 0.355 ms 0.262 ms *
...
$ traceroute 84.148.79.133
traceroute to 84.148.79.133 (84.148.79.133), 30 hops max, 38 byte packets
1 intranator (192.168.0.7) 0.386 ms 0.258 ms *
...

Traceroute mit ICMP:

$ traceroute -I 84.148.79.133
traceroute to 84.148.79.133 (84.148.79.133), 30 hops max, 38 byte packets
1 intranator (192.168.0.7) 0.369 ms 0.255 ms *
...
$ traceroute -I 84.148.79.133
traceroute to 84.148.79.133 (84.148.79.133), 30 hops max, 38 byte packets
1 intranator (192.168.0.7) 0.349 ms 0.267 ms *
...

In jeder Ausgabe von Traceroute ist alle drei Pakete ein "Sternchen" zu sehen, was bedeutet, daß keine Antwort kam.

MfG
Tautenhahn

[Gerd von Egidy]

Hallo,

ok, ich verstehe.

Was für eine Firewallregel verwenden Sie denn für den Rechner mit diesem Problem?

Ich habe es gerade bei uns mit verschiedenen vordefinierten Firewallregeln probiert und bekomme bei Traceroute immer alle Pakete durch wie es sein soll.

Sind Sie sicher, dass der Intranator das Problem ist? Könnte nicht z.B. auch eine Clientseitige Firewall das Problem verursachen?

Herzliche Grüße,

v. Egidy

[Jens Tautenhahn]

Hallo,

der Tip war goldwert. Das Problem besteht nur von einem internen Linux-Rechner aus. Bei diesem läuft allerdings kein iptables / ipchains, es muß also wohl an der Netzwerkkonfiguration des Kernels liegen. Ich werde das noch weiter untersuchen.

Danke für den Tip!

MfG
Tautenhahn