Fritzbox mit Cisco VLAN-Routing - keine Verbindung

Dieses Thema im Forum "AVM (Fritz)" wurde erstellt von HSE, 16. Oktober 2020.

  1. HSE

    HSE Starter

    Registriert seit:
    16. Oktober 2020
    Beiträge:
    5
    Punkte für Erfolge:
    1
    Hallo zusammen,

    seit kurzem setze ich einen professionellen Switch von Cisco in unserem Netzwerk ein. Die Fritzbox 7490 ist dabei zum "normalen" Router degradiert worden, die nur noch der Verbindung von WLAN-Geräten mit dem Netzwerk dient und außerdem die Verbindung ins Internet herstellt. Da die Fritzbox kein VLAN unterstützt, wird das Mapping der Geräte am Switch (mit eingebautem Router) über die MAC-Adresse durchgeführt (Port-Einstellung im Cisco SG350 auf "General" mit Untagged VLANs 100, 110, 111). Die zuweisung der VLANs an die eingehenden Pakete mache ich dynamisch über MAC-Gruppen. Das funktioniert nach anfänglichen Schwierigkeiten jetzt auch ziemlich gut. Der Port steht dazu auf VLAN-Modus General mit den VLANs auf Untagged.

    Folgende Konfiguration macht dann aber Probleme:
    • Handy bucht sich ins WLAN der Fritzbox ein, bekommt per DHCP vom Switch die IP 10.11.10.11/16 und hängt in VLAN 111 mit Gateway 10.11.250.1 (= Switch-IP in VLAN 111)
    • Die Fritzbox hat IP 10.0.0.1/16 und hängt in VLAN 100. Auf der Fritzbox ist eine statische Route mit 10.0.0.0/16 auf 10.0.250.1 (= Switch-IP im VLAN 100). Es läuft die Firmware 7.20.

    Die Kommunikation mit dem restlichen internen Netzwerk funktioniert dabei auch problemlos, auch der Laptop der über einen "normalen" Switch-Port mit VLAN 110 ebenfalls zur Fritzbox und dann ins Internet geroutet wird. Allerdings kann ich mit mobilen Geräten (Android-Handy) keine externen Internet-Seiten aufrufen. Pingen funktioniert allerdings problemlos. Folgende Mechanismen sollten dabei nach meinem Verständnis ablaufen:
    1. ARP-Anfrage nach Standardgateway 10.11.250.1 liefert MAC-Adresse vom Switch/Router
    2. Handy schickt TCP-Paket an Default-Gateway 10.11.250.1 mit Ziel externe IP
    3. Switch/Router liest seine Default-Route mit Gateway 10.0.0.1 (=Fritzbox) und holt sich per ARP die MAC der Fritzbox
    4. Switch/Router forwardet Paket an die Fritzbox, Fritzbox macht NAT und schickt Paket ins Internet
    5. Antwort kommt zurück, wird per NAT auf 10.11.10.11 zurück geschrieben. 10.11.10.11 entspricht der internen Route zu Switch/Router, MAC-Adresse ist bekannt. Paket geht an MAC vom Switch
    6. Switch/Router liest Zieladresse 10.11.10.11, forwardet ins VLAN 111 und zur MAC des mobilen Geräts
    So weit mein Verständnis der Theorie. Um zu ermitteln welches Problem die Verbindung verhindert, wollte ich die Capturing-Funktion der Fritzbox nutzen. Jedes Mal wenn ich jedoch die Aufzeichnung aktiviere, funktioniert auch die Verbindung vom Handy zu beliebigen Seiten. Sobald ich das Capturing beende, ist die Verbindung erneut nicht möglich. Ich kann zur Zeit überhaupt nicht nachvollziehen, warum die Fritzbox sich mit aktivem Capturing komplett anders verhält als ohne.

    Dazu kommt, das eine zweite Fritzbox, die nur als WLAN-Router dient (10.0.0.2, ebenfalls identisches VLAN 100 und auch für die Clients identisches VLAN und Konfiguration am Switch) das besagte Problem erst gar nicht hat. Es scheint also irgendetwas mit dem internen Routing der Fritzbox zwischen LAN und WAN zu tun zu haben.

    Vielleicht hat ja jemand von euch eine Idee was ich da noch probieren könnte..

    Vielen Dank für die Hilfe,
    Tobi
     
  2. HSE

    HSE Starter

    Registriert seit:
    16. Oktober 2020
    Beiträge:
    5
    Punkte für Erfolge:
    1
    Hallo nochmal,

    ich bin zumindest einen ganz kleinen Schritt weiter, kann mir aber nicht erklären warum: Die Admin-Oberfläche der Fritzbox erreiche ich auch nicht, andere HTTP-Server im LAN erreiche ich. Anderen mobilen Clients (Laptop mit WLAN) geht es genau so, es scheint also kein Android-Problem zu sein.

    Was ich überhaupt nicht verstehe ist, das ich alle nicht erreichbaren Hosts trotzdem pingen kann. Alles funktioniert genau so wie es soll, nur bei TCP haut es absolut nicht hin. Die DNS-Auflösung funktioniert über die Fritzbox (10.0.0.1) problemlos, wenn ich den externen Google-DNS 8.8.8.8 per dig ausprobiere bekomme ich keine Antwort.

    Konzeptionell sollte doch ICMP (für die Pings) genau so auf IP aufsetzen wie auch TCP (für HTTP) oder UDP (für DNS)? Irgendetwas muss also die Fritzbox deutlich anders machen was auch noch die auf IPv4 aufsetzenden Protokolle betrifft. Vermutlich hat das irgendwas mit der NAT oder dem Routing der Fritzbox zu tun?

    Habe ich (Fritz OS 7.21) irgendeine Möglichkeit die interne Routing-Tabelle der Fritzbox auszulesen?

    Danke für jede Hilfe,
    Tobi
     
  3. CapFloor

    CapFloor Moderator

    Registriert seit:
    9. August 2010
    Beiträge:
    3.515
    Punkte für Erfolge:
    160
    Hi,

    willkommen im Forum.

    Ich habe bei dieser Konfiguration meine Zweifel, ob das überhaupt funktionieren kann. Warum sollte nicht die FB selbst den ARP-Request für den WLAN-Client beim Antwortpaket beantworten und das Paket direkt zustellen, ohne die Route zum Cisco zu nutzen? Natürlich mit ihrer eigenen IP-Adresse als Absender, so dass das Paket vom Geräte verworfen wird?

    Es gibt im FB-Netz keine durchgängige Trennung der Netzwerke auf Layer 2 und Layer 3. Du darfst die WLAN-Clients nicht über die FB laufen lassen, sondern über einen AP hinter dem Cisco-Switch. Der FB darf nur noch Zugangsrouter für die VLANs hinter dem Cisco sein. Außerdem sollte in diesem Fall an dem Port des Cisco-Switches, an dem die FB hängt, geNATted werden.

    VG
     
  4. HSE

    HSE Starter

    Registriert seit:
    16. Oktober 2020
    Beiträge:
    5
    Punkte für Erfolge:
    1
    Hi,

    ich hatte schon sowas befürchtet. Nach meinem Verständnis sollte aber die Abfrage der Routing-Einträge (und darüber das Ermitteln des nächsten Hops) erfolgen bevor lokal per ARP nach der MAC gefragt wird. Immerhin steht die Fritzbox auf IP 10.0.0.1/16 und das Ziel ist im anderen Subnetz. Natürlich bekommt die Fritzbox die ARP-Messages mit in denen die Zuordnung IP/MAC steht, insofern wäre es durchaus möglich das Paket direkt zuzustellen. Das wäre dann allerdings schon etwas komisch.

    Trotzdem dürfte auch das nicht dazu führen, das die eingehenden Pakete verworfen werden. Immerhin ist ein Default Gateway eben wirklich nur ein "Default" Gateway. Es kann ja durchaus auch mehrere lokale Router im Netzwerk geben - sprich: wenn ein Paket von einer anderen MAC zurück kommt an die der Client es geschickt hat muss das trotzdem funktionieren und der TCP-Stack darf das nicht verhindern.

    Außerdem passt nicht ins Bild, dass die ICMP-Nachrichten alle problemlos durch gehen. Ob da in den Nachrichten jetzt noch Ports und der ganze restliche TCP-Kram drin steht dürfte da ja eigentlich keinen Unterschied machen.. ich werde gleich mal vom Laptop aus per Wireshark mitschneiden was da genau passiert. Eventuell bringt das noch die Erleuchtung.

    Eine Möglichkeit die Routing-Tabelle der Fritzbox auszulesen gibt es nicht, oder? Ich meine.. immerhin hat das Ding ein Packet Capturing-Interface..

    Danke für die Mühe,
    Tobi
     
  5. HSE

    HSE Starter

    Registriert seit:
    16. Oktober 2020
    Beiträge:
    5
    Punkte für Erfolge:
    1
    So.. ich habe ein paar weitere Infos. Es scheint eine Routing-Schleife zwischen Fritzbox und Switch zu entstehen. Ich weiß nur noch nicht, warum das passiert. Siehe dazu das angehängte Wirshark-Trace.

    Die ersten sechs Zeilen sind ein Ping auf 8.8.8.8 - alles funktioniert bestens. In Eintrag Nr. 191 versuche ich per WGET Google zu erreichen. SYN geht hin, SYN/ACK kommt zurück. Mein ACK auf das SYN vom Google-Server kommt jedoch schon nicht mehr durch, genau wie der HTTP GET-Request eine Zeile später - darauf folgt mit Eintrag 195/196 jeweils ein "TTL exceeded" von der Fritzbox. Anschließend sendet mein Laptop den HTTP-Request erneut, der kommt aber auch nicht durch. Gleichzeitig erfolgt die Retransmission des SYN/ACK vom Google-Server, das kommt bei mir dann wieder an.

    Es hat also erstmal nichts damit zu tun, dass der WLAN-Client von der Fritzbox aus "irgendwie komisch" erreichbar wäre. Die MACs in den einzelnen Nachrichten sind auch genau so, wie man sie erwarten würde. Die Fritzbox bringt wohl beim NAT-Eintrag irgendwas durcheinander.

    Ich habe das Ganze mal dem AVM-Support geschildert, eventuell kommt von da noch was erhellendes.

    Falls sonst noch jemand dazu eine Idee hat gerne her damit. Die Routing-Einträge sollten übrigens passen: Auf dem Switch ist die Default-Route über 10.0.0.1 (die Fritzbox) eingetragen, auf der Fritzbox steht 10.0.0.0/8 über 10.0.250.1 (Switch) drin. Das scheint ja soweit auch zu funktionieren, siehe Ping..

    Schöne Grüße,
    Tobi
     

    Anhänge:

  6. CapFloor

    CapFloor Moderator

    Registriert seit:
    9. August 2010
    Beiträge:
    3.515
    Punkte für Erfolge:
    160
    Hi,

    mal schauen, was AVM sagt.

    Grundsätzlich versuchst du, das WLAN und den Switch der FB auf Layer 3 zu trennen, ohne dies auch auf Layer 2 zu tun - was die FB ja nicht kann. Das wird mMn nicht funktionieren. tcp ist stateful, icmp eben nicht...Hast du mal einen udp Verbindung probiert?

    Aber falls du es doch zum Laufen bringen solltest, würde mich die Ursache des jetzigen Problems interessieren.:)

    VG
     
  7. HSE

    HSE Starter

    Registriert seit:
    16. Oktober 2020
    Beiträge:
    5
    Punkte für Erfolge:
    1
    Moin moin,

    der AVM-Support hat sich bis jetzt mit dem Problem beschäftigt und ist leider zu keinem Ergebnis gekommen. Der letzte Kommentar war, dass man den Effekt ohne Switch reproduzieren können müsste, was aber natürlich nicht geht. Ich habe jetzt mal zwei Wireshark-Traces aufgezeichnet, zum Einen vom Laptop, zum Anderen zwischen Fritzbox und Switch (am Monitor-Port des Switches). Folgendes, sehr kuriose Verhalten zeigt sich dabei:

    1. TCP-SYN (IP Laptop -> Google, MAC: Laptop -> Switch). TCP-Flag Syn. TTL = 128
    2. Gleiches Paket (MAC Switch -> Fritzbox). Weitere Daten identisch. TTL = 127

    3. TCP-SYN/ACK (IP Google -> Laptop, MAC: Fritzbox -> Switch). TCP-Flags Syn, Ack. TTL = 123
    4. Gleiches Paket (MAC Switch -> Laptop). Weitere Daten identisch. TTL = 122

    5. TCP-ACK (IP Laptop -> Google, MAC Laptop -> Switch). TCP-Flag Ack. TTL = 128
    6. Gleiches Paket (MAC Switch -> Fritzbox). Weitere Daten identisch. TTL = 127
    7. Gleiches Paket (MAC Laptop -> Switch). Weitere Daten identisch. TTL = 126

    Schritt 6 und 7 wiederholen sich, bis die TTL auf 0 runter ist - dann ist das Paket (klar) weg. Warum in Schritt 7 ein Paket am Switch ankommt welches angeblich vom Laptop stammt, das im Trace des Laptops aber nicht auftaucht kann ich nicht sagen. Eine Sendewiederholung ist es nicht, der Timestamp ist quasi identisch zwischen 5, 6 und 7. Dazu würde auch nicht passen, dass in Schritt 6 das Paket zur Fritzbox geroutet wird, mit eindeutigem Auftrag (nämlich immer noch IP Laptop -> IP Google). Außerdem müsste es, wenn es am Laptop liegt, auch bei Schritt 1 ja schon ein "Echo" geben...

    Ich habe genau das jetzt nochmal zu AVM geschickt, incl. der Traces. Falls jemand hier eine Idee hat bin ich natürlich auch darüber Happy ;-)

    Schöne Grüße,
    Tobi