OpenVPN MultiWAN Umgebung

[lfirewall1243]

Hallo zusammen,

folgendes Szenario habe ich hier.

OPNsense mit 2 WAN Verbindungen, auf der OPNsense läuft ein OpenVPN Server.
Es ist kein Failover o.ä. konfiguriert.

WAN1(default GW)    WAN2
   |                              |
   |                              |
   |                              |
   |------OPNsense-----|

Nun kann ich über WAN1 die VPN Verbindung aufbauen, das klappt alles. Wenn ich WAN2 als default GW hinterlege, kann ich diese auch über WAN2 aufbauen.

Nun möchte ich mich aber über WAN2 verbinden können, während WAN1 das default GW ist.
Dazu habe ich bereits den Haken bei "deaktivere Antwort-an bei WAN Regeln" gesetzt, aber leider ohne Erfolg.
Muss man dazu noch etwas umkonfigurieren?

[superwinni2]

Ich habe hierfür meinen OpenVPN Server auf Localhost am laufen und habe für beide WAN Verbindungen ein entsprechendes Portforwarding gemacht.

[lfirewall1243]

Ich habe hierfür meinen OpenVPN Server auf Localhost am laufen und habe für beide WAN Verbindungen ein entsprechendes Portforwarding gemacht.

Gute Idee.

Das werde ich bei Gelegenheit Mal testen

Danke dir

Gesendet von meinem M2012K11AG mit Tapatalk

[mscd]

Hallo zusammen,

ich arbeite gerade an einem ähnlichen Setup ... was mir derzeit unklar ist:

Worin liegt der Unterschied, falls man bei den OpenVPN-Server-Einstellungen beim listen-interface "any" einstellt, oder man stattdessen das interface "nur" auf "localhost" konfiguriert aber dafür pro WAN-interface ein entsprechendes Port-Forwarding auf localhost konfiguriert?

Wirkt Variante B funktional anders im Multi-WAN-Setup? Irgendwie kann ich da gerade keinen Unterschied erkennen, obwohl diese Vorgehensweise in der Situation OpenVPN + Multi-WAN an diversen Stellen empfohlen wird.

Danke und Grüße,
mdcd

[JeGr]

Das kann sich tatsächlich minimal anders auswirken. Bindet man OVPN bspw. auf Localhost, dann bekommt der Service keinen Interrupt von bspw. WAN o.ä. mit, da er auf einem immer vorhandenen lokalen Interface ist. Er wird also immer gestartet, ist "immer on". Bei Bind an Interface oder any ist das anders, wird dann bspw. ein Interface getrennt oder hat ein Problem mit Kabel, Uptime o.ä. und wird dann down gesetzt/gemeldet, bekommt das der VPN Service auch mit bzw. wird ggf. neu gestartet.

Zudem ist OpenVPNs neues Setting mit "auf alle Interfaces hören" ggf. nicht so ganz das, was man haben möchte, wenn man bspw. in einem HA Setup nur auf die VIPs hören will. Dazu kam dann noch, dass bei Interfaces mit IP4 und IP6 das "an alles Binden" manchmal nur suboptimal geklappt hat.

Daher würde ich in den meisten MultiWAN Szenarien lieber empfehlen den OpenVPN Server auf Localhost zu binden und die eingehenden Verbindungen mit PortForwardings zu realisieren. Damit kann man durch die Forwards sehr genau steuern, auf welche IPs und Ports reagiert wird und auf welche nicht.

Zudem hat man den Luxus, dass man ggf. mehrere verschiedene Ausweichports des gleichen Protokolls nutzen kann da alles auf den gleichen Server weitergeleitet wird. Bsp:

* 1x UDP Server localhost 1194
* 1x TCP Server localhost 1194

von extern dann per forward:

* UDP: 1194, 53, 123, 443
* TCP: 443, 636, 25, 1194

Und zack hat man diverseste Ports an seinen VPN Server durchgereicht. Je nach Location kann das schonmal notwendig werden (schlechte WLANs in Hotels, Flughafen, China, etc.)

Cheers
\Jens