Datenübertragung über OpenVPN in MultiWAN-Umgebung macht Probleme

[skruse]

Hallo,

ich habe hier seit ein paar Tagen ein Problem mit einem OpenVPN-Tunnel.

Sowohl auf Server als auch auf Client-Seite stehen zwei WAN-Netzwerke zur Verfügung.
Serverseitig sind die zwei WAN-Schnittstellen über einen Lastenausgleich verbunden. Clientseitig kommt nur ein Failover zum Einsatz.

Alle WAN-Schnittstellen sind per DDNS-Ansprechbar.

Mein grundsätzliches Setup ist wie folgt:
Server-LAN: 192.168.164.0/24
Client-LAN: 192.168.165.0/24
VPN-Netzwerk: 10.10.0.0/24

Alles ist prinzipiell wie in den Tutorials unter docs.opnsense.org eingerichtet.
Die Einzigen Abweichungen sind, dass ich in der VPN-Konfiguration dynamische IPs zulasse und dass DNS-Server im VPN-Server fest hinterlegt sind.
Die VPN-Verbindung hat anfangs auch ohne Probleme funktioniert.
Den genauen Zeitpunkt - bzw. die ursächliche Konfigurationsanpassung - an dem die Probleme entstanden sind, kann ich nicht genau bestimmen. Meine Vermutung geht aber momentan in richtung MultiWAN-Konfiguration.
Ich habe jetzt schon eininiges ausprobiert, z.B. festes setzen des Gateways in den VPN-Firewall-Rules oder hinzufügen verschiedenster Rules, zu denen ich irgend etwas im Internet gefunden habe. Ausserdem habe ich auch bereits versucht jeweils die zweite WAN-Schnittstelle wieder zu dekativieren. Gebracht hat leider alles nichts.

Der Fehler äußsert sich wie folgt: Die VPN-Verbindung wird anstanmdslos aufgebaut und es werden auch einzelne Datenpakete ausgetauscht (momentan 11KB sent / 11KB received). Ich habe aber keine Chance von einem auf das andere Netzwerk zuzugreifen. Auch Pings schlagen fehl.
Meine Vermutung ist, dass trotz fester Einstellung des Gateways in der Firewall-Rule, Datenströme nicht nur über ein Interface laufen und somit immer nur Datenmüll zwischen den Netzwerken transferiert wird.

VPN-LOG:

Aug 16 16:47:19   openvpn[43732]: MANAGEMENT: Client disconnected
Aug 16 16:47:19   openvpn[43732]: MANAGEMENT: CMD 'status 2'
Aug 16 16:47:19   openvpn[43732]: MANAGEMENT: CMD 'state 1'
Aug 16 16:47:19   openvpn[43732]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Aug 16 16:42:04   openvpn[43732]: MANAGEMENT: Client disconnected
Aug 16 16:42:04   openvpn[43732]: MANAGEMENT: CMD 'status 2'
Aug 16 16:42:04   openvpn[43732]: MANAGEMENT: CMD 'state 1'
Aug 16 16:42:04   openvpn[43732]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Aug 16 16:14:43   openvpn[43732]: Initialization Sequence Completed
Aug 16 16:14:41   openvpn[43732]: Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:18986
Aug 16 16:14:38   openvpn[43732]: UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:18986
Aug 16 16:14:38   openvpn[43732]: UDP link local (bound): [AF_INET]XXX.XXX.XXX.XXX:0
Aug 16 16:14:38   openvpn[43732]: Socket Buffers: R=[42080->42080] S=[57344->57344]
Aug 16 16:14:38   openvpn[43732]: TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:18986
Aug 16 16:14:38   openvpn[43732]: Preserving previous TUN/TAP instance: ovpnc1
Aug 16 16:14:38   openvpn[43732]: Re-using pre-shared static key
Aug 16 16:14:38   openvpn[43732]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

Für mich sieht das alles eigentlich OK aus, aber es kommen eben keine Daten durch.

Hat irgend jemand noch eine Idee, womit das zusammen hängen könnte?

Vielen Dank schon mal für eure Hilfe

[don]

Hallo

Wollte wissen, wie du das Problem gelöst hast? Habe auch Probleme mit Multiwan und openvpn. Allerdings erst seit ein paar Wochen...

Inzwischen habe ich ein Update auf 19.7 gemacht und dort steht folgendes:
OpenVPN no longer supports listening on gateway groups. Use localhost paired with port forwards instead.

Ich hatte das multiwan als failover eingerichtet (failover über 4G sim-Karte) und daher auch eine Gatewaygruppe angelegt.

Allerdings verstehe ich nun die Alternative nicht: Use localhost paired with port forwards instead. Was bedeutet das?

Wenn ich den Port für 4G ausschalte, klappt openvpn wieder. Mittelfristig möchte ich jedoch eine Failover Gruppe haben, die automatisch einschaltet bei Bedarf.

Wäre froh um deinen Lösungsansatz.

Liebe Grüsse
Don

[mfle]

Hallo,

selbes Problem hier. Multiwan OpenVPN verbindet sich, lässt aber keinerlei Traffic durch. Pro WAN-Interface war per NAT -> Port Forward auf die 127.0.0.1 umgeleitet, der OpenVPN-Server auf Interface localhost konfiguriert. Hat 1,x Jahre funktioniert. Seit 19.7 kein Traffic mehr durch den Tunnel.

OpenVPN-Server auf ein WAN-Interface konfiguriert, tut wieder . Leider jetzt ohne Multiwan.

Für eine Lösung wäre ich dankbar.

Gruß

[alh]

Bei mir funktioniert es unter 19.7.2. Anfangs zwar auch nicht aber nach etwas Wartezeit dann doch.

In meinem NAT-Setup (bei mir manuell) war es wichtig das Outbound NAT für localhost (127.0.0.0/8) explizit zu setzen. Masquerading für alles (*) hat nicht funktioniert.

[alh]

Hallo

Wollte wissen, wie du das Problem gelöst hast? Habe auch Probleme mit Multiwan und openvpn. Allerdings erst seit ein paar Wochen...

Inzwischen habe ich ein Update auf 19.7 gemacht und dort steht folgendes:
OpenVPN no longer supports listening on gateway groups. Use localhost paired with port forwards instead.

Ich hatte das multiwan als failover eingerichtet (failover über 4G sim-Karte) und daher auch eine Gatewaygruppe angelegt.

Allerdings verstehe ich nun die Alternative nicht: Use localhost paired with port forwards instead. Was bedeutet das?

Wenn ich den Port für 4G ausschalte, klappt openvpn wieder. Mittelfristig möchte ich jedoch eine Failover Gruppe haben, die automatisch einschaltet bei Bedarf.

Wäre froh um deinen Lösungsansatz.

Liebe Grüsse
Don

Die Alternative heißt, dass du den OpenVPN Server so definierst, dass auf dem Interface "localhost" lauscht. Dann richtest du unter Firewall > NAT Port Forwards von deinen WAN Schnittstellen auf 127.0.0.1 ein. Somit werden Anfragen an z. B. 1194 von deinen WAN-Schnittstellen an den OpenVPN Server auf localhost weitergeleitet. Zu guter Letzt braucht es noch Firewallregeln die ankommenden Traffic wanseitig zulassen, also z. B.

WAN1:

- Allow
- Protocol UDP
- Source *
- Source Port *
- Destination WAN1 address
- Destination Port 1194