Messages

[VPN ‣ OpenVPN ‣ Connection Status]

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?

The 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

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.

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.

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?

Den Quellenfilter habe ich im OpenVPN-Interface, nicht im WAN-Interface, macht das jetzt mehr Sinn? :)

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.

OK, I found the problem, this thread brought it to my attention.

https://www.reddit.com/r/OpenVPN/comments/hi2zgb/openvpn_configuration_not_connecting_to_server/

I didn't actually copy the old key from the legacy settings but created a new one.

Old one is tls-auth, new one is tls-crypt. So I either have to use the old key with auth only or download and distribute all .ovpn files again.

OK, here is a new problem. :-)

OpenVPN server (openvpn_server2) starting:

Code Select Expand

WARNING: --keepalive option is missing from server config
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Could not determine IPv4/IPv6 protocol. Using AF_INET6
Can I ignore the first two warnings? Last warning was a stupid mistake, I selected "UDP" as protocol instead of "UDP (IPv4)". That is fixed at least.

User connecting (old error just to see that it was IPv6):

Code Select Expand

tls-crypt unwrap error: packet authentication failed
TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:xx.xxx.xxx.xxx:34016 (via ::ffff:yyy.yyy.yy.yy%ix0)
User connecting (now correct IPv4):

Code Select Expand

tls-crypt unwrap error: packet authentication failed
TLS Error: tls-crypt unwrapping failed from [AF_INET]xx.xxx.xxx.xxx:53148 (via [AF_INET]yyy.yyy.yy.yy%)
https://forum.opnsense.org/index.php?topic=21602.0

This user says setting the OpenVPN (Connect?) client to UDP4 solved the problem but the default setting in the Connect client is "adaptive" which should automatically decide between TCP and UDP, also the server was always UDP4. So we can rule out the client.

The TLS Shared Key is set to "crypt (Encrypt and authenticate all control channel packets". The same key is selected as "TLS static key" in the instance.

This user got the same problem:

https://forum.opnsense.org/index.php?topic=43784.0

[OpenVPN]

Lately when I updated from OPNsense 24.4.3 to 24.10.2 I also tried to switch from "VPN: OpenVPN: Servers [legacy]" to the new "VPN: OpenVPN: Instances" but I had to cancel that because of an error in the OpenVPN log:

Code Select Expand

Options error: --local addresses must be distinct from --ifconfig addresses
So I used the first address of the OpenVPN pool as "Bind address" which probably was wrong and is a bind to a physical interface and not to a new virtual interface (ovpns2)?

OpenVPN	OPNsense legacy	OPNsense Instances (new)
--ifconfig	"Interface"	"Bind address"
--local	"IPv4 Tunnel Network"	"Server (IPv4)"
--route	"IPv4 Local Network"	"Local Network"
--remote	"IPv4 Remote Network"	"Remote Network"

Is the assignment of the above table correct (Road Warrior setup)? If yes then why does the new "Instances" not have a multi-select field for existing interfaces like the old one did?

There is a new BIOS/BMC bundle containing:

BIOS: 2.2 (12/20/2024)
BMC: 04.02 (06/27/2024) - unchanged
Supermicro Update Manager (SUM): V2.14.0-p9 (10/22/2024)

https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-A2SDi-4C-HLN4F/BIOS

Note from the readme:

Note: For BIOS update with SUM utility through Out-Of-Band (OOB) channel, the SFT-OOB-LIC or SFT-DCMS-Single is no longer required.

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:

You cannot view this attachment.

2. Neuen Alias mit Typ "OpenVPN group" anlegen und dort die Benutzergruppe einfügen:

You cannot view this attachment.

3. Den neuen Alias in den vorhandenen Sammel-Alias für GeoIP einfügen:

You cannot view this attachment.

Muss ich nur noch testen ob das auch funktioniert.

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:

You cannot view this attachment.

Honestly I find the texts harder to read now, I don't know if it's the font itself or the small size of it.

Nur um ein paar Informationen hinzuzufügen: Es handelt sich wohl um einen Intel Ethernet Server Adapter I340-T4 bzw. PRO/1000 PT, entsprechend dann ein Intel 82580 oder 82571 Controller-Chipsatz. Werden beide offiziell vom em(4) Treiber unterstützt.

https://man.freebsd.org/cgi/man.cgi?em(4)
https://www.reddit.com/r/PFSENSE/comments/juvvu4/conflicting_chip_info_on_intel_hp_nc365t_vs/

Letzterer ist aber deutlich älter und könnte für ein Hardware-Problem sprechen.

https://www.intel.de/content/www/de/de/products/sku/41280/intel-82580eb-gigabit-ethernet-controller/specifications.html
https://www.intel.de/content/www/de/de/products/sku/20720/intel-82571eb-gigabit-ethernet-controller/specifications.html

Hello everyone,

I just noticed high inblock packet counts on LAN interfaces which just act as parent interfaces for VLAN interfaces.

How can these high packet numbers be explained, are they originating from the attached switch?

130-200m seem to be a lot of packets per second.

I know the underlying real physical interface of a VLAN does not have to be enabled for a VLAN to be working but I had problems with a WiFi controller and enabling the interface solved it.

The LAN interfaces have the configuration type "none". What would fix these high packet counts without disabling the underlying LAN interfaces?

For comparison I'll show the packet counts of a normal active "Static IPv4" LAN interface vs. a passive LAN interface.

To answer my own question, yes it is only updated once an alias was created.  :D