Hallo zusammen,
gibt es im System Aliase für die externe IP von OpenVPN-Benutzern, so, dass man diese in Firewall-Regeln verwenden kann?
Die Zuordnung gibt es ja bereits im System, siehe im Dashboard die Liste von verbundenen Benutzern:
OPNsense_OpenVPN_client.png
Ich denke ich habe die Lösung schon selbst gefunden:
1. Neue Benutzergruppe für externe Reisende anlegen und die entsprechenden OpenVPN-Benutzer dort zuordnen:
OPNsense_system_access_groups.png
2. Neuen Alias mit Typ "OpenVPN group" anlegen und dort die Benutzergruppe einfügen:
OpenVPN_allowed_users.png
3. Den neuen Alias in den vorhandenen Sammel-Alias für GeoIP einfügen:
OpenVPN_aliases_blur.png
Muss ich nur noch testen ob das auch funktioniert.
Leider funktioniert das so wie ich es eingerichtet habe nicht. Gibt es einen anderen Weg oder ist das was ich will (OpenVPN-Benutzer nach externer IP filtern) aktuell gar nicht möglich?
Ich denke das ist ein wichtiges Business-Feature, da man ja nicht jedes Land komplett für OpenVPN freigeben will, in welches Außendienstmitarbeiter reisen.
Quote from: vpx on April 07, 2025, 01:24:43 PMIch denke das ist ein wichtiges Business-Feature, da man ja nicht jedes Land komplett für OpenVPN freigeben will, in welches Außendienstmitarbeiter reisen.
Das bedeutet aber doch, du willst den generellen Zugriff auf den OpenVPN-Dienst auf Länder einschränken und ggf. einzelne IP-Adressen zusätzlich wieder freigeben? Eine Verbindung von IP-Adresse zu Benutzer sehe ich da erst mal nicht.
Das kannst du ja über eine Firewall-Regel mit GeoIP-Alias problemlos tun.
Oder willst du pro VPN-Benutzer einzelne Länder freigeben oder sperren? Das geht so ohne weiteres m.W. nicht.
Ja, erstmal blockiere ich z. B. für OpenVPN per GeoIP alle Länder außer Deutschland. Jetzt will ich alle OpenVPN-Benutzer in der Gruppe "external" zusätzlich über ihre öffentliche IP freigeben. Das funktioniert aber nicht, deshalb müssen mir die Benutzer im Ausland ihre IP mitteilen und ich trage sie manuell ein.
Das könnte ja automatisch und benutzerbasiert passieren, da OPNsense ja die externe IP des OpenVPN-Benutzers bekannt ist, wie man im Dashboard sieht.
Aber wie sollen die sich verbinden, damit OpenVPN die IP-Adresse an die Firewall-Regel weiterreichen kann, wenn die IP-Adresse doch erstmal gesperrt ist?
Sie können sich erst mit einem VPN Provider verbinden von dem die öffentlichen IP ranges bekannt sind und dann ein VPN im VPN aufbauen.
Mit OpenVPN geht VPN im VPN recht gut, mach ich auf meinem Macbook.
Quote from: Patrick M. Hausen on April 08, 2025, 09:10:54 PMAber wie sollen die sich verbinden, damit OpenVPN die IP-Adresse an die Firewall-Regel weiterreichen kann, wenn die IP-Adresse doch erstmal gesperrt ist?
Den Quellenfilter habe ich im OpenVPN-Interface, nicht im WAN-Interface, macht das jetzt mehr Sinn? :)
Das ergibt überhaupt keinen Sinn. Im OpenVPN-Interface siehst du nur die internen Adressen des Tunnels.
Ich meine das OpenVPN-Interface in der Firewall, es funktioniert ja in der Praxis mit manuell gepflegten Hosts (öffentliche IPs), nur halt nicht benutzerbasiert über die OpenVPN-Benutzer.
Die IP-Adresse muss doch freigegeben sein, damit die Benutzerauthentifizierung überhaupt stattfinden kann ...
Ich hatte mich vertan, der Quellenfilter ist nicht unter "Firewall: Rules: OpenVPN" sondern unter "Firewall: Rules: Floating", angewendet auf die WAN Interfaces.
Die Benutzer-IP die man im Dashboard sieht, wird also vom OpenVPN-Server gezogen? Jetzt verstehe ich das Problem.
Bei VPN gibt es 2 Arten von IP Addressen:
Inner Tunnel IP: Die IP-Adresse, die innerhalb des VPN-Tunnels verwendet wird. Sie gehört zum privaten VPN-Subnetz (z. B. 10.0.0.1) und wird für die Kommunikation zwischen den Endpunkten im Tunnel verwendet.
Outer Tunnel IP: Die öffentliche IP-Adresse des VPN-Endpunkts (z. B. 203.0.113.1), über die der Tunnel im Internet aufgebaut wird.
Stell dir einen Briefumschlag vor:
Die Outer IP ist die Adresse auf dem Umschlag – für die Post (Internet).
Die Inner IP ist die Adresse im Brief – für den eigentlichen Empfänger im VPN.
Das Postoffice (deine Firewall) muss diesen Brief ja erstmal empfangen, um ihn zu öffnen. Der Absender (also die öffentliche IP des Senders) muss also erstmal akzeptiert sein um durch die Tür des Postoffice zu gelangen. Erst danach kann der Brief geöffnet werden um die innere IP (also das was im Brief drin ist) lesen zu können.
Wenn du es also vorher blockierst dann geht das halt nicht.
Quote from: vpx on April 10, 2025, 08:41:11 AMDie Benutzer-IP die man im Dashboard sieht, wird also vom OpenVPN-Server gezogen? Jetzt verstehe ich das Problem.
Die externe IP-Adresse des mobilen Mitarbeiters kommt natürlich nicht vom OpenVPN-Server. Aber wenn die geblockt ist, kann er sich halt überhaupt nicht anmelden. Also muss die IP-Adresse zugelassen sein (auf dem externen Interface, Port 1194 oder was auch immer du verwendest). Erst nachdem die OpenVPN-Verbindung hergestellt ist, weißt du, welcher Benutzer das ist. Und dann hast du eine externe IP-Adresse (immer noch dieselbe) und eine Tunnel-IP-Adresse. Letztere kommt vom OpenVPN-Server. Dann ist es aber schon zu spät, externe Adressen zu blocken oder zuzulassen.
Daher verstehe ich nach wie vor nicht, was du eigentlich beabsichtigst.
Mitarbeiter Müller soll sich nur aus Deutschland anmelden dürfen und Mitarbeiter Schmidt auch aus England? Wieso? Der Sinn des VPN ist doch, über ein unsicheres Netz eine sichere Verbindung herzustellen. Es ist doch genau dafür da, dass es egal ist, wo der Mitarbeiter sitzt und was für ein ISP da evtl. mitschnüffeln will - hat man einen VPN-Tunnel ist der Kram sicher. Wenn man es richtig macht ;-)
Ja das Grundprinzp und der Aufbau von VPNs ist mir schon klar aber ich hatte die zeitliche Abfolge gar nicht bedacht, also, dass die Zuordnung zwischen externer IP und dem OpenVPN-Benutzer erst nach der Authentifizierung stattfindet.
Aber es wäre doch schon ein Schutz gegen Portscans wenn ich erstmal alle Länder blockiere und dann nur die benötigten freischalte. Die Angreifer könnten zwar ein deutsches Botnetz verwenden aber das dürfte schwerer aufzubauen zu sein als z. B. ein chinesisches.
Port Scans finden statt. 24x7. Isso.
Besser davon ausgehen, dass das der Fall ist, als an der Stelle ansetzen, m.M.n. Vergebliche Liebesmüh ...
Quote from: vpx on April 10, 2025, 09:46:39 AM...
Die Angreifer könnten zwar ein deutsches Botnetz verwenden aber das dürfte schwerer aufzubauen zu sein als z. B. ein chinesisches.
Das bezweifle ich stark.
Wenn deine Clients einen DynDNS-Service konfiguriert haben und ihre public IP da hinterlegen, kannst du am WAN für deinen openVPN Port nur diese IPs zulassen. Besser als nüscht.
Eine Sache noch: Wenn ich unter "Firewall: Diagnostics: Aliases" den Alias vom Typ "OpenVPN group" auswähle, erscheinen dort keine IPs, auch keine internen.
Laut der Dokumentation sollten hier die gleichen IPs wie im Verbindungsstatus stehen?
QuoteThe current users that are logged into OpenVPN can be inspected via VPN ‣ OpenVPN ‣ Connection Status, the alias just follows this information and flushes the attached addresses to the item in question.
https://docs.opnsense.org/manual/aliases.html#openvpn-group
Mir ist gerade eingefallen, dass der Benutzer den ich im Verbindungsstatus gesehen hatte, gar nicht in der Gruppe war, habe mich testweise hinzugefügt und man sieht tatsächlich nur die interne Pool-IP.