3
Wireguard-client hinter Mikrotik und Fritzbox - handshake initiation-packets werden durch FB nicht ins WAN geroutet
Hallo zusammen,
ich benötige eure Hilfe bei einem Problem, das mich inzwischen einige Tage Recherchen und Tests/Analysen (mit Mikrotik-packet sniffer, Fritzbox-capture und wireshark) gekostet hat und zu dem ich aber auch im Netz bislang keine Hinweise gefunden habe. Daher bin ich euch für jeden Hinweis zu einer möglichen Ursache oder Lösungsansätzen dankbar.
Hintergrund: Der bislang direkt an eine Fritzbox (FB) 7490 angeschlossene Windows-Rechner im Büro meiner Frau soll künftig als „Client“ über ein Wireguard (WG)-VPN an einen entfernten „Server“ angeschlossen werden. Außerdem soll er zusätzlich – in einem inneren Netz - durch einen Mikrotik (MT) hap ax³ als Router und Firewall geschützt werden. Sämtliche anderen Geräte (Multifunktionsgerät, VOIP-Telefone, WLAN-angebundenes Smartphone meiner Frau) sollen im äußeren Netz der Fritzbox verbleiben. Mit wenigen Ausnahmen (z.B. Druck) soll sämtliche Kommunikation des Windows-Rechners nur noch durch den WG-VPN-Tunnel und die Infrastruktur hinter dem externen WG-Server abgewickelt werden.
Um den MT bis Ende Oktober vorzubereiten und die künftige Strecke WG-Client => MT => FB => … vor der Installation im Büro meiner Frau zu testen, habe ich zuhause folgenden Testaufbau (allerdings mit meiner Fritzbox 7590 AX) installiert:
Der MT ist soweit eingerichtet und mit Firewall-Regeln und einem Masquerade als srcnat versehen. Pings (auch entlang der oben rot eingezeichneten problembehafteten Pfade) und auch normaler http/https-Internetverkehr (sofern entsprechende Firewall-Regeln temporär deaktiviert sind) laufen wie gewünscht. Alles super!
Das Problem besteht nun allerdings beim WG-Verbindungsaufbau. Dabei werden die von einem WG-client auf Position I (siehe ganz links im Bild) versendeten Wireguard-handshake initiation-Pakete durch die Fritzbox „verschluckt“. Zwar landen sie auf der „Routing-Schnittstelle“ (Bezeichnung von der capture-Seite der FB http://fritz.box/#cap) der FB, werden aber durch diese nicht (ge-NAT-tet natürlich) auf ihre eigene wan-Schnittstelle durchgelassen. Logischerweise kann somit auch keine Tunnelverbindung aufgebaut werden.
Sobald ich einen WG-client allerdings direkt an die FB anschließe (Position II in der Bildmitte unten), werden die handshake-Pakete (mit NAT natürlich) durchgereicht, der VPN-Tunnel wird aufgebaut und die weitere Übertragung läuft wie geschmiert.
Ursachenforschung: Im Rahmen meiner (inzwischen langsam verzweifelten) Suche nach einer möglichen Ursache, zumindest jedoch deren Eingrenzung, habe ich folgende – teilweise vielleicht seltsam oder überflüssig anmutende – Konstellationen getestet:
1. Tests mit Änderungen im MT: Selbst wenn ich in der Mikrotik
a* als erste Firewall-Regel ein accept für alles zulasse (somit die MT-Firewall außer Kraft setze),
b* das scrnat-Masquerade ausschalte (somit die Pakete an der FB mit 192.168.100.x ankommen; für den Rückweg wäre in der FB eine static route auf den MT (192.168.178.249) für die betreffende 192.168.100.x/32-Adresse vorstellbar),
c* alternativ zu b eine srcnat auf eine andere ungenutzte und außerhalb deren eingerichteten DHCP-Bereichs (.20 - .200) liegende fiktive FB-Netz-Adresse (z.B. 192.168.178.7) vornehme (Rückweg wäre auch hier über eine static route in der FB sowie ein dstnat in der MT vorstellbar),
d* die TTL im postrouting (wg. des MT-Routings) um 1 inkrementiere (falls die FB wg. des TTL-Wertes meinen sollte, die WG-Pakete nicht durchleiten zu müssen/sollen/können/dürfen/wollen),
bleibt das Problem bestehen, dass bereits die handshake initiation-Pakete aus der Strecke WG-client => MT => FB in der FB „verschluckt“ werden.
2. Auch mit im WG-client herabgesetzter MTU bleibt das Problem bestehen (wobei die handshake initiation-Pakete sowieso wesentlich kleiner sind).
3. Tests mit WG-Server im FB-Netz: Nachdem ich einen WG-server auf einem zweiten Raspberry Pi im FB-Netz eingehängt habe, habe ich nachgeprüft, dass von beiden WG-clients aus dem inneren MT-Netz eine funktionstüchtige WG-Verbindung auf den WG-server des Pi innerhalb des FB-Netzes möglich ist. Innerhalb des FB-Netzes somit alles super!
4. Tests mit dem WG-Server der FB 7590 AX selbst:
a* vom WG-client aus dem MT-Netz über die interne IP der FB (192.168.178.1): läuft perfekt (btw: auch vom WG-client im FB-Netz)!
b* auf die öffentliche IP der FB (188.x.x.x):
b.1* mit WG-client im FB-Netz(!): läuft super! btw: Wireshark-Analyse des capturings der FB zeigt, dass die Pakete (handshake und weitere kompletter VPN-Verkehr) direkt in der FB auf deren WG-server geroutet werden (werden also auch nicht an die wan-Schnittstelle durchgereicht und somit nicht erst durch das Internet geleitet, was ja auch ein Umweg wäre)
b.2* mit WG-client im MT-Netz: läuft nicht (wie leider erwartet)
Schlussfolgerung aus diesen Tests: Grundsätzlich (aufgrund meines netzwerktechnischen laienhaften Halb- wenn nicht nur Viertelwissens wahrlich nicht generell !) würde ich ausschließen, dass es an der Einrichtung der WG-clients liegt oder an den Firewall-Regeln oder NAT-Maßnahmen der MT liegt. Stattdessen würde ich die Ursache grundsätzlich irgendwo im Routing der Fritzbox verorten, die offensichtlich die WG-handshake initiation-Pakete vom MT – warum auch immer – nicht ins Internet weiterleiten mag (bzw. selbst viel zu gerne mag und einfach verschluckt).
Vielleicht mag es aber auch an – für mich allerdings nicht erkennbaren – Unterschieden der über den MT gerouteten handshake initiations-Pakete liegen. Diese unterscheiden sich meines Erachtens (jedoch: Halb-/Viertelwissen!) nicht nennenswert (siehe nachfolgende Abbildung: rot umrandet = aus MT-Netz (mit NAT) stammend, grün umrandet = aus FB-Netz stammend). Rein spekulative(!) Frage:
Oder könnte es evtl. an Unterschieden auf Level 2 liegen, wo ich mich allerdings so überhaupt nicht auskenne und mir auch nicht bekannt ist, wie ich Unterschiede mit Hilfe welcher Systeme herausfinden könnte.
Welche möglichen Ursachen oder Lösungen kämen noch in Frage? Oder hattet ihr auch schon dieses Problem (oder ein ähnliches mit MT und FB) und konntet dieses – idealerweise – bereits lösen? Wer oder was könnte sonst helfen?
Auf eure zahlreichen Antworten hoffend und gespannt sowie mit vielen Grüßen
Christof
ich benötige eure Hilfe bei einem Problem, das mich inzwischen einige Tage Recherchen und Tests/Analysen (mit Mikrotik-packet sniffer, Fritzbox-capture und wireshark) gekostet hat und zu dem ich aber auch im Netz bislang keine Hinweise gefunden habe. Daher bin ich euch für jeden Hinweis zu einer möglichen Ursache oder Lösungsansätzen dankbar.
Hintergrund: Der bislang direkt an eine Fritzbox (FB) 7490 angeschlossene Windows-Rechner im Büro meiner Frau soll künftig als „Client“ über ein Wireguard (WG)-VPN an einen entfernten „Server“ angeschlossen werden. Außerdem soll er zusätzlich – in einem inneren Netz - durch einen Mikrotik (MT) hap ax³ als Router und Firewall geschützt werden. Sämtliche anderen Geräte (Multifunktionsgerät, VOIP-Telefone, WLAN-angebundenes Smartphone meiner Frau) sollen im äußeren Netz der Fritzbox verbleiben. Mit wenigen Ausnahmen (z.B. Druck) soll sämtliche Kommunikation des Windows-Rechners nur noch durch den WG-VPN-Tunnel und die Infrastruktur hinter dem externen WG-Server abgewickelt werden.
Um den MT bis Ende Oktober vorzubereiten und die künftige Strecke WG-Client => MT => FB => … vor der Installation im Büro meiner Frau zu testen, habe ich zuhause folgenden Testaufbau (allerdings mit meiner Fritzbox 7590 AX) installiert:
Der MT ist soweit eingerichtet und mit Firewall-Regeln und einem Masquerade als srcnat versehen. Pings (auch entlang der oben rot eingezeichneten problembehafteten Pfade) und auch normaler http/https-Internetverkehr (sofern entsprechende Firewall-Regeln temporär deaktiviert sind) laufen wie gewünscht. Alles super!
Das Problem besteht nun allerdings beim WG-Verbindungsaufbau. Dabei werden die von einem WG-client auf Position I (siehe ganz links im Bild) versendeten Wireguard-handshake initiation-Pakete durch die Fritzbox „verschluckt“. Zwar landen sie auf der „Routing-Schnittstelle“ (Bezeichnung von der capture-Seite der FB http://fritz.box/#cap) der FB, werden aber durch diese nicht (ge-NAT-tet natürlich) auf ihre eigene wan-Schnittstelle durchgelassen. Logischerweise kann somit auch keine Tunnelverbindung aufgebaut werden.
Sobald ich einen WG-client allerdings direkt an die FB anschließe (Position II in der Bildmitte unten), werden die handshake-Pakete (mit NAT natürlich) durchgereicht, der VPN-Tunnel wird aufgebaut und die weitere Übertragung läuft wie geschmiert.
Ursachenforschung: Im Rahmen meiner (inzwischen langsam verzweifelten) Suche nach einer möglichen Ursache, zumindest jedoch deren Eingrenzung, habe ich folgende – teilweise vielleicht seltsam oder überflüssig anmutende – Konstellationen getestet:
1. Tests mit Änderungen im MT: Selbst wenn ich in der Mikrotik
a* als erste Firewall-Regel ein accept für alles zulasse (somit die MT-Firewall außer Kraft setze),
b* das scrnat-Masquerade ausschalte (somit die Pakete an der FB mit 192.168.100.x ankommen; für den Rückweg wäre in der FB eine static route auf den MT (192.168.178.249) für die betreffende 192.168.100.x/32-Adresse vorstellbar),
c* alternativ zu b eine srcnat auf eine andere ungenutzte und außerhalb deren eingerichteten DHCP-Bereichs (.20 - .200) liegende fiktive FB-Netz-Adresse (z.B. 192.168.178.7) vornehme (Rückweg wäre auch hier über eine static route in der FB sowie ein dstnat in der MT vorstellbar),
d* die TTL im postrouting (wg. des MT-Routings) um 1 inkrementiere (falls die FB wg. des TTL-Wertes meinen sollte, die WG-Pakete nicht durchleiten zu müssen/sollen/können/dürfen/wollen),
bleibt das Problem bestehen, dass bereits die handshake initiation-Pakete aus der Strecke WG-client => MT => FB in der FB „verschluckt“ werden.
2. Auch mit im WG-client herabgesetzter MTU bleibt das Problem bestehen (wobei die handshake initiation-Pakete sowieso wesentlich kleiner sind).
3. Tests mit WG-Server im FB-Netz: Nachdem ich einen WG-server auf einem zweiten Raspberry Pi im FB-Netz eingehängt habe, habe ich nachgeprüft, dass von beiden WG-clients aus dem inneren MT-Netz eine funktionstüchtige WG-Verbindung auf den WG-server des Pi innerhalb des FB-Netzes möglich ist. Innerhalb des FB-Netzes somit alles super!
4. Tests mit dem WG-Server der FB 7590 AX selbst:
a* vom WG-client aus dem MT-Netz über die interne IP der FB (192.168.178.1): läuft perfekt (btw: auch vom WG-client im FB-Netz)!
b* auf die öffentliche IP der FB (188.x.x.x):
b.1* mit WG-client im FB-Netz(!): läuft super! btw: Wireshark-Analyse des capturings der FB zeigt, dass die Pakete (handshake und weitere kompletter VPN-Verkehr) direkt in der FB auf deren WG-server geroutet werden (werden also auch nicht an die wan-Schnittstelle durchgereicht und somit nicht erst durch das Internet geleitet, was ja auch ein Umweg wäre)
b.2* mit WG-client im MT-Netz: läuft nicht (wie leider erwartet)
Schlussfolgerung aus diesen Tests: Grundsätzlich (aufgrund meines netzwerktechnischen laienhaften Halb- wenn nicht nur Viertelwissens wahrlich nicht generell !) würde ich ausschließen, dass es an der Einrichtung der WG-clients liegt oder an den Firewall-Regeln oder NAT-Maßnahmen der MT liegt. Stattdessen würde ich die Ursache grundsätzlich irgendwo im Routing der Fritzbox verorten, die offensichtlich die WG-handshake initiation-Pakete vom MT – warum auch immer – nicht ins Internet weiterleiten mag (bzw. selbst viel zu gerne mag und einfach verschluckt).
Vielleicht mag es aber auch an – für mich allerdings nicht erkennbaren – Unterschieden der über den MT gerouteten handshake initiations-Pakete liegen. Diese unterscheiden sich meines Erachtens (jedoch: Halb-/Viertelwissen!) nicht nennenswert (siehe nachfolgende Abbildung: rot umrandet = aus MT-Netz (mit NAT) stammend, grün umrandet = aus FB-Netz stammend). Rein spekulative(!) Frage:
Oder könnte es evtl. an Unterschieden auf Level 2 liegen, wo ich mich allerdings so überhaupt nicht auskenne und mir auch nicht bekannt ist, wie ich Unterschiede mit Hilfe welcher Systeme herausfinden könnte.
Welche möglichen Ursachen oder Lösungen kämen noch in Frage? Oder hattet ihr auch schon dieses Problem (oder ein ähnliches mit MT und FB) und konntet dieses – idealerweise – bereits lösen? Wer oder was könnte sonst helfen?
Auf eure zahlreichen Antworten hoffend und gespannt sowie mit vielen Grüßen
Christof
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43025012902
Url: https://administrator.de/contentid/43025012902
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo @Brautraum,
Keiner hier analysiert gern auf Glaubensbasis. Wer mag, glaubt in der Kirche. Konfigurations-Exports vom MT, Screenshots der FB-Einrichtung und Paketmitschnitte real statt in Prosa wären nicht schlecht.
Ich glaube nicht, dass die Fritzbox magisch unterscheiden kann, ob ein WG-Paket an extern von einem Client innerhalb ihres Netzes oder von einem NAT-Router (auch innerhalb ihres Netzes) geschickt wird.
Wenn ich es richtig verstehe (Zeichnung), funktioniert ja die Verbindung von einem Client aus dem FB-Netz zur externen Gegenstelle. Ergo liegt der Hase wohl in der Mikrotik-Konfiguration oder beim Client dahinter.
Viele Grüße, commodity
würde ich ausschließen, dass es an der Einrichtung der WG-clients liegt oder an den Firewall-Regeln oder NAT-Maßnahmen der MT liegt
Grundsätzlich:Keiner hier analysiert gern auf Glaubensbasis. Wer mag, glaubt in der Kirche. Konfigurations-Exports vom MT, Screenshots der FB-Einrichtung und Paketmitschnitte real statt in Prosa wären nicht schlecht.
Ich glaube nicht, dass die Fritzbox magisch unterscheiden kann, ob ein WG-Paket an extern von einem Client innerhalb ihres Netzes oder von einem NAT-Router (auch innerhalb ihres Netzes) geschickt wird.
Wenn ich es richtig verstehe (Zeichnung), funktioniert ja die Verbindung von einem Client aus dem FB-Netz zur externen Gegenstelle. Ergo liegt der Hase wohl in der Mikrotik-Konfiguration oder beim Client dahinter.
Viele Grüße, commodity
Hallo commodity,
danke für deine Antwort. Du hast natürlich recht: dokumentierte Fakten sind besser als Schilderungen. Im Rahmen der Zusammenstellung der Infos ist mir übrigens noch aufgefallen, dass die FB bei der aus dem MT-Netz heraus erfolgenden WG-handshake initiation jeweils mit einem ICMP-Paket antwortet, das von der MT (aufgrund der auf "accept all" eingestellten Firewall) zu dem dahinter liegenden WG-Client durchgereicht wird. Dieser antwortet jedoch nicht. Bei dem gleichen WG-Client im FB-Netz schickt die FB jedoch kein solches Paket, sondern routet brav an den WG-Server weiter.
Leider war diese seltsame ICMP-Reaktion der FB auch nicht geeignet, mich als Laien in die richtige Lösungsrichtung zu bringen. Durch puren Zufall (weil ich aufgrund der offenen MT-Firewall mich davon überzeugen wollte, dass ich bei dem ganzen Hin und Her jegliches port-forwarding und alle static routes deaktiviert habe) bin ich jedoch dann auf die eigentliche Lösung gekommen. Bevor ich sie preisgebe, möchte ich zu meiner Ehrenrettung sagen, dass ich vor einer Woche bereits einen anderen MT (allerdings ohne den ganzen WG-Schnickschnack) in meinem Netz aufgesetzt habe und da (natürlich! - ironie off) an genau diejenige Einstellung gedacht habe, die hier jetzt fehlte. Ich habe schlicht und ergreifend vergessen, in der FB unter "Filter" das Kindersicherungsprofil der neuen MT von „Standard“ auf ein ausreichend Rechte besitzendes Profil zu ändern. Aaaarrrrgggghhhh! Ein richtige dummer Anfängerfehler, für den ich mich in den A....llerwertesten beißen könnte angesichts der rund 40 Stunden vergeudeter Lebenszeit (na gut, ein bisschen habe ich dabei auch gelernt). Also lag es an der Fritzbox bzw. eigentlich an ihrem „DAU“😉. Keine Magie, kein Layer 2-Thema (wobei die Fritzbox anhand der in den ersten 3 Byte der MAC-Adresse codierten Herstellerkennung erkennen könnte, dass es sich um ein Gerät eines Wettbewerbers handelt 😉), sondern nur ein blödes Versäumnis meinerseits.
Dir nochmals einen herzlichen Dank für deine Bereitschaft, dich mit dem Problem auseinanderzusetzen.
Viele Grüße
Christof
danke für deine Antwort. Du hast natürlich recht: dokumentierte Fakten sind besser als Schilderungen. Im Rahmen der Zusammenstellung der Infos ist mir übrigens noch aufgefallen, dass die FB bei der aus dem MT-Netz heraus erfolgenden WG-handshake initiation jeweils mit einem ICMP-Paket antwortet, das von der MT (aufgrund der auf "accept all" eingestellten Firewall) zu dem dahinter liegenden WG-Client durchgereicht wird. Dieser antwortet jedoch nicht. Bei dem gleichen WG-Client im FB-Netz schickt die FB jedoch kein solches Paket, sondern routet brav an den WG-Server weiter.
Leider war diese seltsame ICMP-Reaktion der FB auch nicht geeignet, mich als Laien in die richtige Lösungsrichtung zu bringen. Durch puren Zufall (weil ich aufgrund der offenen MT-Firewall mich davon überzeugen wollte, dass ich bei dem ganzen Hin und Her jegliches port-forwarding und alle static routes deaktiviert habe) bin ich jedoch dann auf die eigentliche Lösung gekommen. Bevor ich sie preisgebe, möchte ich zu meiner Ehrenrettung sagen, dass ich vor einer Woche bereits einen anderen MT (allerdings ohne den ganzen WG-Schnickschnack) in meinem Netz aufgesetzt habe und da (natürlich! - ironie off) an genau diejenige Einstellung gedacht habe, die hier jetzt fehlte. Ich habe schlicht und ergreifend vergessen, in der FB unter "Filter" das Kindersicherungsprofil der neuen MT von „Standard“ auf ein ausreichend Rechte besitzendes Profil zu ändern. Aaaarrrrgggghhhh! Ein richtige dummer Anfängerfehler, für den ich mich in den A....llerwertesten beißen könnte angesichts der rund 40 Stunden vergeudeter Lebenszeit (na gut, ein bisschen habe ich dabei auch gelernt). Also lag es an der Fritzbox bzw. eigentlich an ihrem „DAU“😉. Keine Magie, kein Layer 2-Thema (wobei die Fritzbox anhand der in den ersten 3 Byte der MAC-Adresse codierten Herstellerkennung erkennen könnte, dass es sich um ein Gerät eines Wettbewerbers handelt 😉), sondern nur ein blödes Versäumnis meinerseits.
Dir nochmals einen herzlichen Dank für deine Bereitschaft, dich mit dem Problem auseinanderzusetzen.
Viele Grüße
Christof
Prima, danke für das Feedback.
Lag ich doch gar nicht so falsch, dass da keine "Magie" eingreift.
Und das ist auch der Grund, weshalb man gern einen Blick auf die Konfiguration wirft. Das mit dem "Aaargggh" kennen wir ja alle
Du zahlst natürlich auch den Preis für ein eher problematisches Setup. Die Kaskade mit einer Fritzbox - noch dazu mit einem "produktiven" Netz vor dem Mikrotik - ist unnötig und kann immer wieder mal Probleme machen. Gerade dem nichtprofessionellen Admin ist mit einem klaren Setup am Ende besser gedient.
Meist ist ja der Grund, dass man irgendwelche Fritzbox-Features (welche?) weiter nutzen will. Dann hängt man die FB aber besser hinter den Mikrotik in ein selbständiges Netz und davor ein ordentliches Nur-Modem. Das ganze wird noch weniger sinnvoll, wenn Du, wie Du es planst, ein Loch zum Drucken bohren musst.
Aber viele Wege führen nach Rom und oft müssen die Dinge ja auch reifen. Kommt die Zeit, verschwindet die Fritzbox dann fast von allein ...
Viele Grüße, commodity
Lag ich doch gar nicht so falsch, dass da keine "Magie" eingreift.
Und das ist auch der Grund, weshalb man gern einen Blick auf die Konfiguration wirft. Das mit dem "Aaargggh" kennen wir ja alle
Du zahlst natürlich auch den Preis für ein eher problematisches Setup. Die Kaskade mit einer Fritzbox - noch dazu mit einem "produktiven" Netz vor dem Mikrotik - ist unnötig und kann immer wieder mal Probleme machen. Gerade dem nichtprofessionellen Admin ist mit einem klaren Setup am Ende besser gedient.
Meist ist ja der Grund, dass man irgendwelche Fritzbox-Features (welche?) weiter nutzen will. Dann hängt man die FB aber besser hinter den Mikrotik in ein selbständiges Netz und davor ein ordentliches Nur-Modem. Das ganze wird noch weniger sinnvoll, wenn Du, wie Du es planst, ein Loch zum Drucken bohren musst.
Aber viele Wege führen nach Rom und oft müssen die Dinge ja auch reifen. Kommt die Zeit, verschwindet die Fritzbox dann fast von allein ...
Viele Grüße, commodity
