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.
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 🙂
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 :)
Quote from: Patrick M. Hausen on May 05, 2025, 09:12:07 PM...Ich versuche immer, adressbasierte Firewall-Regeln so weit wie möglich zu vermeiden.
und
Quote from: JeGr on May 09, 2025, 12:41:50 PM...Daher bei OVPN Regeln (oder WG etc.) immer Source mit angeben.
äääähhh, also
Quote from: JeGr on May 09, 2025, 12:41:50 PMIch 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?
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 :-(
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.
Quote from: Patrick M. Hausen on May 05, 2025, 09:12:07 PMMan 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... ;-)
Quote from: wagman77 on May 11, 2025, 04:26:30 PMOb 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.
Quote from: chemlud on May 09, 2025, 05:32:32 PMQuote from: Patrick M. Hausen on May 05, 2025, 09:12:07 PM...Ich versuche immer, adressbasierte Firewall-Regeln so weit wie möglich zu vermeiden.
und
Quote from: JeGr on May 09, 2025, 12:41:50 PM...Daher bei OVPN Regeln (oder WG etc.) immer Source mit angeben.
äääähhh, also
Quote from: JeGr on May 09, 2025, 12:41:50 PMIch 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?
Sorry die Antwort ging irgendwie unter und wurde mir jetzt erst als Benachrichtigung angezeigt.
Du hast da meine Posts in falscher Reihenfolge zusammengestückelt - so hab ich das ja absichtlich nicht geschrieben. Aber zugegeben, man hätte vielleicht die entsprechenden Sätze quoten sollen.
Was mit Zustimmung gemeint war: wir richten auch einzelne Server pro User(gruppe) VPN ein. Mitarbeiter VPN ist da strikt von Admin oder Dienstleister VPN getrennt.
Was die Firewall Regeln angeht: auch da stimme ich zu keine ADRESSbasierten Regeln zu machen. Also kein Schnick mit "User X bekommt bei Einwahl IP Y zugewiesen und wird damit dann gefiltert". Das geht meistens schief. Und ist unflexibel und inkompatibel wenn der User multiple Einwahlen braucht, bspw. Phone/Laptop gleichzeitig. Das müssen dann extra eigene User/Zerts sein, umständlich und fehleranfällig. Und niemand mag da wirklich gern Dutzende CSOs administrieren.
Daher meine Aussage bezüglich "kein ANY bei Source Address" in Firewallregeln vom OpenVPN Gruppeninterface. Wenn man da Any nimmt hat man schnell was freigegeben, was bei einem später hinzugefügten Server dann ins Auge geht. Daher immer das Netz vom entsprechenden Einwahlserver als Source, dann kann es auch keine versehentliche Freigabe für bspw. Dienstleister geben. Dito und noch schlimmer fürs Admin RAS Netz.
> Natürlich muss man jeder weiteren OpenVPN-Instanz ein Interface zuweisen und eine Firewall Regel erstellen, sonst spielt da nicht.
Nein muss man nicht. OpenVPN Einwahlserver ziehen keinen Nutzen daraus, wenn man das Interface zuweist. Lediglich die Regelvergabe auf dem Interface mag einfacher sein, das kann man aber wie oben beschrieben problemlos mit sauberen Regeln und "Source" Angabe auf dem OpenVPN Gruppeninterface genauso machen. Zuweisung bringt nur dann was, wenn ich das Interface (gegenüber) bspw. aktiv Monitoren lassen möchte (weil ein zugewiesenes Interface im Routing/Gateway Monitoring auftaucht) oder wenn ich PBRs brauche (policy based routes) - was aber meistens auch nur bei Site2Site Tunneln der Fall ist. Hier macht das dann absolut Sinn. Bei Einwahl VPNs eher nicht.
Cheers :)
Gruppen-Interface mit Netz der Server-Instanz als Source - clever, danke! :)