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