Messages

Bei IPv4 Tunnel Network kannst du die IP-Adresse rein schreiben. Steht doch daneben: "Push virtual IP endpoints for client tunnel, overriding dynamic allocation."

Sorry Patrick, war wohl das Problem mit dem Wald und dem Baum ;)

War mit dem Kopf irgendwie versteift darauf ein equivalent für "ifconfig-pool-persist /conf/ovpn-user-ipp.txt" zu finden.

Sorry Patrick, aber ich aus der Anleitung nicht schlau:

https://docs.opnsense.org/manual/vpnet.html#id6

Das sind dieselben Optionen, die ich auch unter Instances habe, jedoch eine Möglichkeit dem Client aus dem Subnet 1982.168.0.0/24, die IP 192.168.0.8/24 fest zuzuordnen lese ich da nicht heraus, oder verstehe diese falsch.

Bisher funktionierte das so:
Unter VPN - OpenVPN - Client Specific Overrideseinen neuen Eintrag anlegen, bei "Common name" den Benutzername oder den common name des Zertifikats (je nach Konfiguration) eintragen und im Feld "Advanced" dann die gewünschte IP-Adresse hinzufügen:

"ifconfig-push 10.0.8.2 255.255.255.0;"

Unbedingt beachten sollte man, das die erste IP-Adresse bereits für den OpenVPN-Server vergeben ist, also immer erst ab der zweiten Adresse mit der Vergabe beginnen! Ggf. muss der OpenVPN-Server neu gestartet werden, damit die Änderungen greifen.

Update 02/2024

Offenbar wurde in der Zwischenzeit etwas verschlimmbessert. Jedenfalls der hier beschriebene Weg funktioniert nicht mehr (Version 24.1). Schlimmer noch, die bestehenden Einstellungen sind wohl weg. Im Dateisystem unter

client-config-dir /var/etc/openvpn-csc/1

findet man auch nichts mehr. Vielleicht wird oder wurde es auch woanders gespeichert ?

würde empfehlen den Pi-Hole durch das Adguard-Plugin zu ersetzen - ähnlich effektiv und läuft direkt auf der Sense

Moin Gemeinde,

hat schon mal jemand versucht OpenVPN-Usern feste IPs zuweisen zu lassen?

Hintergrund: Nicht jeder muss immer überall hin, Personaler brauchen die Perso-DB, andere sollten da besser nicht hineinsehen können.

Natürlich kann man das auch über unterschiedliche Instances lösen, das würde aber mutiple GWs erzeugen und damit unnötigen Overhead.

Freue mich über eure Infos - Danke im Voraus ;)

[NAT ist nicht gleichzeitig ARP]

Und zu diesem Fall: NAT ist nicht gleichzeitig ARP, auch wenn du es gerne so haben würdest.
Nicht immer, wenn man eine Weiterleitung braucht,  will man gleichzeitig die ursprüngliche Ziel-IP auch dem Router zugeordnet haben. Wofür auch??
Das sind verschiedene Dinge für unterschiedliche Anwendungsfälle.

Warum das andere namhafte Hersteller so machen, wär mir rätselhaft.

Naja, wirklich sauber ist es, wenn NAT+ARP eingetragen wird, schließlich sollte Layer 2 auch funktionieren, ohne Gateway of last Resort als Notnagel.

Warum namenhafte Hersteller das so handhaben?
Naja, sie möchten die Konfiguration "vereinfachen", damit auch die arme Sau, die das aufgedrückt bekommt, das ohne zweiwöchige Schulung hin bekommt.
Leider hat nicht jedes KMU die Ressourcen für einen echten Security-Admin/CISO etc.

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