Messages

NAT passiert eben nicht auf Layer 2. Das ist Netzwerkstandard und die Kenntnis darüber sollte Voraussetzung sein, wenn man mit OPNsense startet.
So steht es auch in den Docs > Introductions.

NAT Regeln würden in deinem Fall aber auch ausreichen, wenn die IP auf deine geroutet werden würde.

Komisch dass bei anderen Herstellen wie Sophos oder Cisco ein Eintrag ausreicht?
Oder willst Du mir erzählen, dass die dort alle keine Netzwerkstandards kennen?

Manche Software bedient sich halt wie eine Behörde, wo man alles doppelt und dreifach braucht, damit man eine Chance bekommt sich selbst zu widersprechen.

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.'

Richtig. NAT ist nur Layer 3. Proxy-ARP ist böse, will man normalerweise nicht.

Die Anleitungen sind echt gut, daher wäre gut, wenn jemand vielleicht einen Vermerk mit aufnimmt, wie .... Damit das sauber funktioniert muss die betroffene IP noch als Virtuelle IP eingetragen werden .... oder so ähnlich.

Bin da nicht der einzige, der in diese Falle tappt.

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

Sorry für die späte Rückmeldung,
habe nochmals mit dem Kollegen auf der anderen Seite reden wollen, bevor Missverständnisse aufkommen.
Der Kollege auf der anderen Seite sagte er sähe zwar die Packete kommen, die MAC-Adressen jedoch würde sein L3 Switch nicht lernen, die blieben bei "incomplete"
Im Capture sehe ich die Packete jedoch mit der Adresse vom physikalischen Interface von der Primären Sense raus gehen.
Habe daraufhin mal ins Proxmox geschaut, dort sehe ich auch "nur" die physikalischen Adressen und die CARP-Interfaces.
Bin bisher davon ausgegangen, dass Adressen die ich im 1:1 NAT eintrage, auch via Arp übermittelt werden (Arp-Proxy)- dem scheint nicht so zu sein.
Daher habe ich die 1:1 Nat-Adressen jetzt ebenfalls bei Carp mit eingetragen, damit sie mit dem Cluster wandern.

Jedenfalls sieht man die NAT-IPs jetzt auch im Proxmox mit der MAC vom physikalischen Inteface, ebenso meldet dies auch der Kollege auf der anderen Seite, die Arp-Tabelle wäre jetzt okay.

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.

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.

Wir haben bisher auch die Credentials nicht im Client gecached, aber den Benutzern empfohlen, sie in der Mac OS Keychain zu speichern. Die ist bis auf weiteres erst mal als sicher angesehen.

Für Windows-Menschen scheint Keypass dieses Problem ebenfalls gut zu lösen - wird dennoch gerne von Usern bemängelt, weil man halt ein seperates Masterpasswort unabhängig vom Login benötigt.

Nachtrag:

Mittlerweile gibt es einen Punkt beim Client Export:

"Enable static challenge (OTP)"

Fügt das Eingabefeld für TOTP hinzu

Das gibt glaube ich beim Tunnelaufbau immer eine Warnmeldung ?

Ja, in der OpenVPN GUI kommt da eine schöne rote Zeile. Daran habe ich mich schon gewöhnt. :-)

Die Alternative wäre eben, die Zugangsdaten jeweils nach der Renegotiation Time neu einzugeben. Macht beim empfohlenen 1 Stunden-Intervall auch keinen Spaß.

Finde es auch Legitim wenn die User Benutzer / Passwort abgespeichert haben

Ich kenne keinen Weg, das zu unterbinden.

Hier suggeriert der Wortlaut "Disable password save" im OPNsense OpenVPN Client Export auch mehr als die Option in der Realität zu bewirken vermag. Die Instanthilfe verrät aber eh, was es tatsächlich tut. Es fügt die Zeile "auth-nocache" in die Client Konfig ein, die dem Client veranlasst, das Passwort bzw. den Auth-Token nicht im Cache zu halten. Das Speichern des Passworts am Client verhindert es nicht.

Klarer Fall von Etikettenschwindel ;)

Habe bei mir jetzt alle Legacy Tunnel umgestellt, da ja eine EOL Notice erscheint

[Was die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?]

Was die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?

Weil man seine DNS-Anfragen nicht einem US-Konzern geben will?

Naja, es hat auch den Vorteil DNS beliebig manipulieren zu können und seinen Pool an Geräten mit passenden Namen zu versorgen - das gilt jetzt nicht nur für Unbound, passt aber so in diesen Kontext.

Na Du machst mir Hoffnung JeGr.

Habe auch schon festgestellt, dass DNS und Openvpn eine echt tolle Kombination sind ...
Das ist sowas von Client-Software-abhängig, dass man es eigentlich nur ausprobieren und immer ausschließlich 1:1 so nachbauen kann.
Jede Änderung kann komplett anderes Verhalten zur Folge haben - Vorhersagen sind da bestenfalls inspirierte Ratespiele. 

wenn du das Szenario genauer erklärst, dann kann man besser helfen :)

ich versuchs mal zu erklären :

User-Netz > OpnSense > Transfer-Netz > VPN-Router > Dienstleister (Serverfarm)

Man hat sich mit dem Dienstleister darauf geeinigt Server des Dienstleisters zu erreichen, indem man teils 1:1 User-Adressen auf Transfer-Netz-Adressen NATet, um damit bestimmte Server zu erreichen. Für einige Dienste braucht es jedoch keine eindeutige Zuordnung (1:N-Nat).
1-N funktioniert, 1:1 macht Probleme.

Bisher hat das eine andere Software erledigt, die auf Grund ihres Alters (der Kollege der dies betreute ist nicht mehr), gegen eine OpnSense getauscht werden soll.

Theoretisch ist das möglich, wenn man einen Split-Tunnel baut und 2 DNS-Server übergibt:

"der erste ist ein öffentlicher, wie z.b. 8.8.8.8 und der zweite ein interner, welcher über den Tunnel auflöst.
Hat der erste keine Antwort, wird der zweite DNS gefragt, erst wenn der auch nicht weiter weiß gibt es keine Antwort."

Gebaut habe ich sowas allerdings noch nicht - weil DNS nur minimal Traffic verursacht und ich die Kontrolle nicht an Google und co abgeben möchte.