VPN über Dual WAN

  • Moin Leute,

    ich habe eine Cloud Gateway Max und dort Dual WAN im Failover aktiv.

    WAN 1 = 100 Mbit Telekom - Public IPv4 ohne CGNAT

    WAN 2 = 5G Telekom - Public IPv4 ohne CGNAT

    Zur Ausgangssituation: Da ich verschiede Sites habe, die alle zu mir sicher, würde ich gerne mein SITE VPN´s über WAN 2 laufen lassen, da sonst meine WAN 1 immer dicht ist.

    Die angebundenen Sites sind alles Fritzboxen und wurde wie in diesem Thread beschrieben angebunden.

    Die Sites haben alle in der Wireguard Config meine DynDNS Domain hinterlegt.

    Was habe ich bereits getestet:

    • im Wireguard Server auf WAN2 gestellt
    • Die DynDNS wird Public auch Sauber auf WAN2 aufgelöst
    • VPN auf beiden Seiten neugestartet

    Leider verbinden sich die Site weiterhin mit WAN1 und machen schön Ihr Backup´s darüber.

    Jemand noch einen Denkanstoß?

    VG

  • Hmm, das Ganze erscheint mir unlogisch. Wenn ein VPN-Client sich von außen verbindet, kennt er ja nur die IP-Adresse am WAN 2 (über DynDNS) und weiß nichts über WAN 1.

    Das Initiieren der Verbindung muss also zwingend über WAN 2 laufen.

    Ich könnte mir jetzt höchsten vorstellen, dass Unifi irgendeine schräge Automatik fährt und den Tunnel im laufenden Betrieb umschaltet, weil WAN 2 bei Dir ja nur als Failover und nicht als Loadbalancing konfiguriert ist.

    Wie genau das technisch funktionieren würde, ist mir allerdings komplett schleierhaft.

  • Ok es wird immer wilder....

    vor WAN1 hängt eine Fritzbox mit entsprechenden Portweiterleitungen für die UniFi.

    Ich habe mal diese Portweiterleitung für den Wireguard Server deaktiviert, die Fritzbox an WAN1 neu gestartet und das CG Max neu gestartet.

    Verhält sich immer noch gleich und mir ist schleierhaft wie die FritzBox den Port an die CG Max weitergibt....

  • Wireguard ist hier und da anders als andere VPNs. Server und Client oder Teilnehmer einer S2S Verbindung gibt es ja prinzipiell nicht. Die Konfiguration ist da ziemlich gleich. Rein spekulativ von mir, passiert vermutlich folgendes:

    Im "Server" also der UDM sind für die Peers keine öffentlichen IPs hinterlegt. Der Client hat eine IP oder einen DDNS Namen für den Server. Also kann der CLient auch nur die Verbindung initialisieren. Dazu wird beim Start bei vielen Wireguard Implementationen der DDNS einmalig in eine IP umgewandelt und die Verbindung initialisiert. Der Tunnel steht über WAN2. Die UDM entscheidet sich jetzt aber die Wireguard Pakete über WAN1 an die öffentliche IP zu senden, die er für den Peer erlernt hat. Das macht dann in der Fritzbox eine ausgehende Verbindung auf.

    Da der Client jetzt für den Peer Pakete von einer anderen IP erhält, die auch noch korrekt verschlüsselt sind, Wechselt der Wireguard Client die öffentliche IP die zu diesem Peer gehört und Antwortet dorthin. Mir ist nur unklar warum das klappt ... liegt wohl irgendwie am NAT auf der Seite des Clients *schulterzuck*

    Da die Fritzbox eine ausgehende Verbindung registriert hat, kommen die Pakete auch bei der UDM ohne Portweiterleitung an.

    Wie man das jetzt hinbiegen kann, kann ich aus dem stehgreif nicht sagen. Failover ist allerdings wohl nicht geeignet für die WANs, da die UDM ja dann WAN2 nicht nutzen soll. Also ggf. Distributed einstellen, ggf. WAN1 und 2 tauschen und alle Geräte/Netzwerke mit policy based routing auf WAN2 stellen ... das könnte klappen. Für die UDM selbst gelten die policy based routen ja nicht. Da müsste man dann statische routen in die UDM frickeln mit den öffentlichen IPs der VPN Peers als Ziel und dem entsprechenden WAN Port... Wenn die Peers aber keine feste IP hat, müsste man dort gleich ganze Providernetze eintragen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!