Verständnisfrage zu Openvpn - User in unterschiedliche Netzwerkesegemente

[wagman77]

Hallo zusammen,

seit ca. 2 Jahren befasse ich mich mit OPNSense. In meinem Homelab verprobe ich das, was ich später in unserer kleinen Firma ausrolle.
Aktuell migriere ich eine kleine kommunale Verwaltung von Sophos UTM9 nach OPNSense.
Natürlich sollen die Verwaltungsmitarbeiter von zu Hause aus über VPN arbeiten können. Meine Herausforderung ist, dass ich über OpenVPN sowohl einen Zugriff auf mein Management-Netz (Server, Switches, AccessPoints usw.) haben möchte, aber zugleich einen Zugriff auf mein "User-Vlan" möglich sein muss. Die User möchte ich nicht in den IP-Adress-Bereich meines Mgmt-VLANs lassen.
Ich habe das so gelöst, dass ich zwei Instanzen (Instances) anlegt habe. Über die eine Instanz greife ich auf die Mgmt-Netze zu, die andere ist auf den IP-Adress-Bereich meines User-Vlans beschränkt.

Meine Frage ist: Macht man da so? Ist das "best pratice"? Oder gibt es andere Möglichkeiten?
Trotz intensiver Recherche im Web habe ich nichts brauchbares gefunden.

Danke für euren Input.

[Patrick M. Hausen]

Man könnte den Usern natürlich auch IP-Adressen fix zuweisen und dann mit Firewall-Regeln und diesen Adressen arbeiten. Ich persönlich bin aber kein Fan davon. Ich würde es wie du mit zwei getrennten VPN-Servern/Instanzen einrichten.

Ich versuche immer, adressbasierte Firewall-Regeln so weit wie möglich zu vermeiden. Separation macht man über Netzsegmente. Jedenfalls wenn man "old school" ist wie ich 🙂

[JeGr]

Ich würde mich da Patrick anschließen. Richten wir so auch nicht ein. Wir splitten das in VPN Server für bspw. Mitarbeiter, Admins und Contractor - also irgendwelche Fremdfirmen. Beim Contractor VPN werden keine Routen gepusht, kein DNS etc. und die Clients tatsächlich via CSO bzw. Radius mit fixen IPs bestückt, damit man die mit Regeln sauber "einsperren" kann. Bei Admins will man eh alles erlaubt haben auf Management und Co und Mitarbeiter bekommen nur was gehen muss und nicht mehr.

Die 3 Server (oder mehr) bekommen alle unterschiedliche IP Segmente und damit kann man die Regeln auch ordentlich auf dem OpenVPN GruppenInterface durchkonfigurieren. Wer auf dem OpenVPN bei uns ne "Any zu XY" Regel anlegt, bekommt Haue ;) Denn das geht meistens schief, sobald was dazu kommt, neuer RAS Server, neue Site2Site o.ä. - und prompt dürfen Sachen mehr als sie sollten. Daher bei OVPN Regeln (oder WG etc.) immer Source mit angeben.

Cheers :)

[chemlud]

...Ich versuche immer, adressbasierte Firewall-Regeln so weit wie möglich zu vermeiden.

und

...Daher bei OVPN Regeln (oder WG etc.) immer Source mit angeben.

äääähhh, also

Ich würde mich da Patrick anschließen.

verstehe ich was falsch oder sind da deutliche UNTERSCHIEDE zwischen den Posts was FW-Regeln für VPN anbelangt?

[wagman77]

Danke für die hilfreichen Tipps. Eine zweite OpenVPN Instanz war schnell angelegt. Ich habe dazu einfach meine "Admin"-Instanz geklont und die Netzwerksegmente zugewiesen, die für die User vorgesehen sind. Die entsprechenden Netze kann ich ohne weiteres pingen, aber irgendwas ist falsch.
Der mit OpenVPN verbundene Client geht nicht "ins Internet" und ich kann mich auch nicht per RDP zu einem der "erlaubten" Server verbinden :-(

[wagman77]

Wie so oft sitzt das Problem vor dem Rechner. Natürlich muss man jeder weiteren OpenVPN-Instanz ein Interface zuweisen und eine Firewall Regel erstellen, sonst spielt da nicht. Ob das mit meiner "any to any" Regel auf meinem "UserVPN-Interface" richtig ist, sei mal dahin gestellt. Zumindest tut es so und die User könnne keine der Management Oberflächen von meinem MGMT VLAN aufrufen.

[Reiner030]

Man könnte den Usern natürlich auch IP-Adressen fix zuweisen und dann mit Firewall-Regeln und diesen Adressen arbeiten.

Das "könnte" man, wenn denn meine handvoll Issues mit jeweiligen Teil-Patch der entsprechenden Bug Fixes dazu letztes Jahr nicht mit "you are a dumpster" abgewiesen worden wären, ohne diese genauer anzusehen.

Wir wollen u.a. auch so die User etwas "ordnen" und auch je eine fixe Adresse im /24er Subnetz geben, aber nach jetzt fast einem Jahr funktionieren die Dinge noch immer nicht und ich muss jetzt in der aktuellen "OPNsense 25.4-amd64" daher zum vierten mal die immer noch die nicht gefixten Bugs jedes mal aufwändig nachpatchen und prüfen, was sich zwischendurch alles für den Patch relevantes geändert hat...

Für diesen Fall:
Wenn man statische IPs an Clients binden will, benötigt man neben dem z.B. 192.168.1.0/24-er Netz eine Konfigurationszeile, um den dynamischen IP Zuweisungsbereich vom Standard Client Netz einzuschränken, wiez.B.

ifconfig-pool 192.168.1.128 192.168.1.250 255.255.255.0
(2.7-er Dokumentation: "ifconfig-pool start-IP end-IP [netmask]" )

und optional weitere Dinge wie ein push-reset Bug in der OPNsense, um die Routen zu "nullen" und dabei auch die "subnet" (und keepalive) Konfigurationszeile bei dem jeweiligen Client zu verlieren, was in "VPN: OpenVPN: Client Specific Overrides" als Hilftetext der Option (im Advanced Mode) sogar selbst von den Admins eingepacht wurde:
   
Don't inherit the global push list for a specific client instance.
NOTE: --push-reset is very thorough: it will remove almost all
options from the list of to-be-pushed options. In many cases,
some of these options will need to be re-configured afterwards -
specifically, --topology subnet and --route-gateway will get lost
and this will break client configs in many cases.

Aber "wie üblich" wissen Programmierer und Entwickler immer am besten, was User - oder hier Admins - "wirklich" benötigen und was nicht... ;-)

[Reiner030]

Ob das mit meiner "any to any" Regel auf meinem "UserVPN-Interface" richtig ist, sei mal dahin gestellt. Zumindest tut es so und die User könnne keine der Management Oberflächen von meinem MGMT VLAN aufrufen.

Für den Anfang vollkommen ausreichend insbesondere zum Testen.
Die Routen in die lokalen Netzwerke kann man schon durch die zu pushenden "Local Network" Bereiche einschränken, in dem die Mitarbeiter sicher auch normal "freien" Zugang haben.
Zusätzlich kann man sicherheitshalber die any => any Firewall Regeln auf dem Interface zu gleichwertigen "OpenVPN Netzwerk"=> "Netzwerk-Routen" Firewall Regeln aufsetzen, um auch unwahrscheinliche "manuell gesetzte Routen" von den Clients zu blocken.