mehrere unabhängige OpenVPN Zugänge auf mehreren Interfaces

[trixter]

Moin Gemeinde,

hat schonmal jemand mehrere unabhängige OpenVPN Zugänge auf mehreren Interfaces gebaut?

Gemeint ist zum Beispiel: Interface Opt1 mit Carp-IP 195.90.05.10 für die Admins, Interface Opt2 mit Carp-IP 10.11.11.1 für CoWorker im Wlan, beide bekommen unabhängige VPN-Netze und damit unterschiedliche Zugangsrechte im Unternehmen.

Bisher habe ich unterschiedliche VPNs auf dem Selben Interface gebaut, das klappt mit getrennten Zugangsports und Gruppen ganz gut, jetzt wollen wir das Wlan umbauen und ein weiteres internes Interface käme zum Cluster hinzu.

Erste Versuche sahen bisher nicht erfolgversprechend aus, daher meine Frage ob die OpnSense das überhaupt managen kann - also OpenVPN an mehreren unabhängigen Interfaces?

Danke fürs Helfen.

[viragomann]

Hallo,

das habe ich so auf OPNsense noch nicht gemacht, doch fällt mir auch kein Grund ein, weswegen es nicht funktionieren sollte.

Unterschiedliche Ports würde ich aber versuchen, wenn mit gleichen die 2. Instanz nicht startet. Denn ich weiß nicht,  ob OPNsense / OpenVPN die Bindung tatsächlich nur an eine IP macht.

daher meine Frage ob die OpnSense das überhaupt managen kann - also OpenVPN an mehreren unabhängigen Interfaces?

Was verstehst du unter "unabhängig" in diesem Zusammenhang?

Die OPNsense wird üblicherweise als Router und Upstream-Gateway eingesetzt. D.h., jedes daran angeschlossene Gerät mit Ausnahme des WAN Gateways schickt Traffic, der für außerhalb des eigenen Subnetzes bestimmt ist, da hin. Da ist es weitgehend egal, auf welchem Interface (tatsächlich: IP) ein Dienst lauscht. Sofern es die Firewall-Regeln erlauben, geht das Paket dahin und der Service verarbeitet es.

Das bedeutet für dein Beispiel, lauscht ein OpenVPN Server auf der WAN IP, kann man sich mit diesem auch vom internen IoT Subnetz verbinden, wenn es die Firewall zulässt. Das gilt auch für jede andere Interface IP.
Demnach ist es auch egal, ob mehrere OpenVPN Server auf einer oder unterschiedlichen IPs laufen. Konfiguriere einfach die Firewall Regeln entsprechend.

Grüße

[osmom]

Hast du auf den neuen WAN-Interface auch die Regeln für OpenVPN so gesetzt wie auf dem bestehenden?

[trixter]

Wenn Du Firewall-Regeln meinst, ja.
Habe für beide Interfaces eine passende Regel Tcp, Source=any, Destination=This Firewall, Port 1199 ....
Wobei ich intern UDP und einen anderen Port nutze, um Logs besser lesen zu können.

[trixter]

Hallo,

das habe ich so auf OPNsense noch nicht gemacht, doch fällt mir auch kein Grund ein, weswegen es nicht funktionieren sollte.

Unterschiedliche Ports würde ich aber versuchen, wenn mit gleichen die 2. Instanz nicht startet. Denn ich weiß nicht,  ob OPNsense / OpenVPN die Bindung tatsächlich nur an eine IP macht.

daher meine Frage ob die OpnSense das überhaupt managen kann - also OpenVPN an mehreren unabhängigen Interfaces?

Was verstehst du unter "unabhängig" in diesem Zusammenhang?

Die OPNsense wird üblicherweise als Router und Upstream-Gateway eingesetzt. D.h., jedes daran angeschlossene Gerät mit Ausnahme des WAN Gateways schickt Traffic, der für außerhalb des eigenen Subnetzes bestimmt ist, da hin. Da ist es weitgehend egal, auf welchem Interface (tatsächlich: IP) ein Dienst lauscht. Sofern es die Firewall-Regeln erlauben, geht das Paket dahin und der Service verarbeitet es.

Das bedeutet für dein Beispiel, lauscht ein OpenVPN Server auf der WAN IP, kann man sich mit diesem auch vom internen IoT Subnetz verbinden, wenn es die Firewall zulässt. Das gilt auch für jede andere Interface IP.
Demnach ist es auch egal, ob mehrere OpenVPN Server auf einer oder unterschiedlichen IPs laufen. Konfiguriere einfach die Firewall Regeln entsprechend.

Grüße

Mit unabhängig meine ich, dass ich tatsächlich verschiedene Interfaces nutze, für die WLAN-Leute, welche Zugang zu internen Freigaben benötigen nutze ich ein OPT-Interface mit UDP-1194 (Pool 192.168.200.0/24), für die Externen, die für Diagnosezwecke an eine eigene DMZ müssen, nutze ich das WAN mit TCP-1199 (Pool 172.30.30.0/24).

Somit hat kein beteiligtes Element eines Tunnels etwas mit dem anderen zu tun, selbst die Zertifikate sind eigene.

Die Instanz auf OPT funktioniert bestens, die auf dem WAN jedoch nicht - finde auch keine Fehlermeldung die mir einen sinnvollen Hinweis gibt.
Daher bin ich etwas Ratlos

Somit haben die Zugänge

[viragomann]

Somit hat kein beteiligtes Element eines Tunnels etwas mit dem anderen zu tun,

Das ist ohnehin gegeben, wenn die Server auf unterschiedlichen IP / Port Kombinationen lauschen, was Bedingung ist.

Die Instanz auf OPT funktioniert bestens, die auf dem WAN jedoch nicht

Hast du schon überprüft, ob am WAN überhaupt was von den Clients ankommt?

[osmom]

Hast du bei den Instances unter "Bind address" die jeweilige IP des Interfaces eingetragen?
Ich nehme jetzt mal an das du auf der WAN-Seite den Port für OpenVPN auf die Firerwall zulässt?
Falls Ihr für WAN ein Transfehrnetzwerk habt, must du bei "Bind addresse" die IP der Opensense für dieses Netz eintragen. So war es bei  mir, ich habe aber kein Cluster.

[Patrick M. Hausen]

Lasst "Bind address" doch einfach leer, was bedeutet: 0.0.0.0/0. Thema durch. Ist die robusteste Konfiguration.

[trixter]

Lasst "Bind address" doch einfach leer, was bedeutet: 0.0.0.0/0. Thema durch. Ist die robusteste Konfiguration.

Bind address leer lassen, würde bedeuten er lauscht auf allen IPs nach dem entsprechenden Port?
Hatte bisher die CARP-WAN-Adresse drin, so läufts auch auf der OPT für die WLan-User.
Regeln hab ich auch 2x gegengecheckt, die lassen den entsprechenden TCP-Port durch auf "This Firewall", werde mal zu konkreten IP umbauen ...
Hast schon recht, dann kann man das nicht vergessen ;) Ist zum testen sicherlich auch nicht falsch.

Bekomme immer diese vielsagende Fehlermeldung, wenn ich versuche die 2te Instanz zu starten:

/usr/local/opnsense/scripts/openvpn/ovpn_service_control.php: The command '/usr/local/sbin/openvpn --config '/var/etc/openvpn/instance-7393dcc5-c2ed-4ac4-a0c3-81f372097bb9.conf'' returned exit code '1', the output was 'Options error: error parsing --server parameters Use --help for more information.'