Speedtouch versendet keine ICMP Redirects

Betreibt man sein SpeedTouch (in meinem Fall ST546i) in einer komplexeren Routingkonfiguration kann man mitunter einen Nachmittag brauchen um den Fehler zu finden wieso bestimmte Pakete einfach nicht geroutet werden. Nach stundenlangem Debugging mit Packetsniffern findet man dann: Das Speedtouch versendet (manchmal) gar keine ICMP Redirects!

Szenario

Das Szenario ist - zugegebenermaßen - sehr komplex:

     logger                                  gate                          AP
 192.168.200.112    ---------------->  192.168.200.120  /---------->  192.168.0.10
     ^               (defaultroute)      192.168.0.7 --/                [Antwort]
     |                                                                      |
     |                                                                      |
     |                                                        (defaultroute)|
     |                                                                      |
     |              gate      [2]   fresnel      [1]  SpeedTouch <----------+
     |          192.168.0.7 <----- 192.168.0.2 <----- 192.168.0.1
     +------ 192.168.200.120

[1] route add 192.168.200.0/24 via 192.168.0.2
[2] route add 192.168.200.0/24 via 192.168.0.7

Die Komplexität rührt daher dass das Netzwerk einerseits gewachsen ist (d.h. die Routen sind historisch bedingt), andererseits gibt es Geräte die keine Eingabe von manuellen Routen erlauben sodass die Defaultrouter im Netz Routen verteilen sollen (ICMP Redirects).

Im konkreten Fall soll ein Datenpaket von "logger" zu "AP" geschickt werden. Witzigerweise hat das mit UDP Paketen funktioniert, jedoch nicht mit ICMP bzw. TCP Paketen.

Der Hinweg führt über den Defaultrouter "gate" direkt hin zum "AP". Kritisch wird die Rückantwort. Denn Der AP hat lediglich ein Defaultgateway getragen. Das war jahrelang ein Linuxrouter. Dieser wurde jedoch Anfang des Jahres defekt wodurch dieser 1:1 durch das Modem (ST546i) ausgetauscht wurde. Dieses Modem hat (historisch begründet) folgende Route für das 200er Netz eingetragen:

:ip rtadd dst=192.168.200.0/24 gateway=192.168.0.2

192.168.0.2 ist "fresnel", ein Rechner, der früher direkt ins 200er Netz geroutet hat. Dies hat seit längerem "gate" direkt übernommen, weshalb auf fresnel ebenfalls folgende Route eingetragen ist:

ip route add 192.168.200.0/24 via 192.168.0.7

Bei der Rückantwort muss nun das SpeedTouch einen ICMP Redirect zu AP senden: "Sorry, aber schicke deine Pakete nochmals an 192.168.0.2". Dort geschieht nun das gleiche: "Sorry, ich bin 192.168.0.2, aber schicke deine Pakete bitte nochmals an 192.168.0.7". Erst 192.168.0.7 (gate) schickt dann die Pakete über ein weiteres Interface ins 200er Netz.

Das große Problem am Debugging war nun dass so viele Rechner beteiligt waren, darunter Embdedded Geräte auf die man schwer (WRT54GL) bis gar nicht (SpeedTouch) ein tcpdump installieren konnte. Erschwert wurde die Suche nun dadurch dass das SpeedTouch sehr wohl ICMP Redirects gesendet hat. Im ganzen Paketedschungel war es aber schwer festzustellen dass diese ständig für andere Stationen gesendet wurden.

Problemlösung

Der erste Schritt ist zu überprüfen ob das SpeedTouch überhaupt ICMP Redirects sendet. Nachdem ich diese bereits in den tcpdumps gesehen habe dürfte das wohl so sein:

:ip config
       Forwarding                     enabled
       Sendredirects                  enabled
       IP options                     transparent
       NetBroadcasts                  disabled
       Default TTL                    64
       Fraglimit                      64
       # Fragmented packets           0
       Defragment mode                enabled
       Address checks                 dynamic
       Mss Clamping                   enabled
       NAT Loopback                   enabled
       ARP Cache timeout              900 sec
       ARP class                      4

"Send redirects" muss hier auf enabled stehen. Ist dies nicht der Fall:

:ip config redirects=enabled

Das eigentliche Problem war nun die Firewall! Entweder die Firewall komplett deaktivieren oder eine Ausnahmeregel hinzufügen.

Allerdings funktioniert auch:

:firewall config icmpchecks=disabled

was bei mir das Problem gelöst hat.

Kommentare

<comments />