Die Firewall Regeln überprüft? Das kan man gerne übersehen...
Hilfreich ist "Packet Capture" über alle Interfaces, das man per WebGUI oder per Download in WireShark prüfen kann und mir schon bei einem Problem die Tage geholfen hat.
Der ping/das Traceroute sind "normal" ; große Provider loadbalancen ihren Traffic über mehrere Strecken / Remote IPs auf den jeweiligen Routern.
Ich muss allerdings auch diverse extreme Verschlimmbesserungen zwischen meinem Februar und dem heutigen Test für eine OpenVPN Umstellung von pfSense auf OPNsense von 24.1 auf 24.1.2 feststellen, die eine Migration zur Zeit unmöglich machen.
Scheinbar werden die neuen virtuellen OpenVPN Instanzen als so relevant angesehen, dass man die QA für bisherige Systeme nicht mehr macht - weil es sowieso funktioniert bzw. veraltet ist ... ???
0) Routing funktioniert gut - wenn man auf die FW Regeln achtet ;-)
1) jetzt "Legacy - Disabled LZO algorithm (--comp-lzo-no)" erzeugt im Serverlog diverse Stub Fehlermeldungen
"Bad compression stub decompression header byte"
und im Client minütige Reconnects mit OpenVPN Connect 3.3.x oder 3.4.x Clients mit der Fehlermeldung:
"TUN write exception: write_some: asio.system error"
die ebenfalls auf die Compression als Ursache hingewiesen hat.
Konnte ich nur umgehen durch umstellen auf Enabled-LZ4v2 / Stubv2 (und vielleicht auch weitere nicht getestete Optionen)
2) Client Overrides ... werden "ignoriert" ... Lt. Log wird NICHTS angewendet:
"Notice openvpn Locate overwrite for '' using server '1' (vpnid: 1"
EDIT: Das konnte ich mit dem "neuen" Interface validieren und lösen: das "Username as CN" ist "schön"
in den Advanced Options versteckt, wird aber für das Override benötigt
(sonst "leer" - auch in der Status Übersicht weshalb ich auf die Lösung gekommen bin)
3) NTP Parameter "kennt" OpenVPN nicht mehr ?
EDIT: ist ein Client (deprecated?) Update Problem
4) Die per Radius übergebenen Routing Optionen, die ich meiner Erinnerung nach letztes Jahr und noch im Februara ebenfalls bei OPNsense OpenVPN sehen konnte (hier kamen sie bei jedem Rekeying; bei der pfSense nur beim 1. Login), sind komplett verschwunden ...
EDIT: Ich sehe noch nicht mal mehr beim Verbindungsaufbau die entsprechenden Informationen im Radius
tcpdump obwohl /usr/local/opnsense/mvc/app/library/OPNsense/Auth/Radius.php noch alle Parameter enthält.
5) ... und die Remote IP Übergabe an den Auth Prozess fehlte sowieso schon, die für sauberes protokollieren / MFA Verfahren nötig ist.
... scheinbar wird man "gezwungen" auf das neue virtuelle Setup zu gehen, jedoch sehe ich da im ersten Überblick bei weitem nicht die nötigen Optionen wie im bisherigen OpenVPN Setup...
So, nachdem ich die meisten anderen Aufgaben für einen Wechsel von pfSense zu OPNsense abgeschlossen habe und erneut OpenVPN prüfe, muss ich feststellen, dass für die neuen "Instances" nicht nur die Konfigurationsoberflläche, sondern auch das Rad neu erfunden wurde bzw. die Konfiguration der OpenVPN Server.
Und dabei wurde anscheinend mit dem "professionellen Tunnelblick eines Programmierers" vieles übersehen und die Admins dürfen jetzt mit quadratischen bis hexagonalen Reifen durch die Gegend fahren...
Die neuen Instanzen Overrides werden - an sich gut angedacht - jetzt beim Start einer Sitzung in z.B.
/var/etc/openvpn-csc/1/reiner für die erste OpenVPN Instanz per User festgezurrt, um Sessions Token nutzen zu können, ohne zwischendurch die Routen zu verlieren (das passiert uns noch bisher bei pfSense mit den Radius Routen, so dass wir diese fest in den OpenVPN Server eintragen mussten).
Dabei hat man allerdings die Funktion
fehlerhaft umgeschrieben/verwendet, denn
- als erstes wurden die Overrides für die "Legacy Instanzen" lt. Treffern hier und Github anscheinend "vergessen" weiterhin einzubinden, was inzwischen gefixt wurde.
- die dort enthaltenen Routen werden neuerdings zusätzlich gerouted und nicht stattdessen
- insbesondere fehlen hier sämtliche per Radius gepushte Routen. - sie werden einfach nicht mehr ausgelesen und übernommen...
Ganz einfach so ... nicht.
Braucht ja auch keiner, auch wenn es Dutzende von Anleitungen zu dem Thema alleine für OPNsense dafür existieren. - wie schon zuvor wird die Client IP nicht korrekt an den Radius Server gesendet
(Das hat pfSense in 2.6.0 verbuggt und sogar wieder in (Redmine #12817) (https://redmine.pfsense.org/issues/12817) unerwartet zügig behoben bzw. haben ihn bei einem weiteren Patches dieses Jahr wieder erzeugt gem Kommentaren in Redmine #8087 (https://redmine.pfsense.org/issues/8087)...
Leider ist nur diese Funktion in OPNsense total anders gelöst und daher noch nicht mal in ähnlicher Form aufzufinden. ) - Man kann zwar weiterhin im Override eine feste Instanz-IP von z.B. 192.168.180.4/24 per IPv4 Tunnel Network definieren, aber einen Ersatz Eintrag/Option im Server für die benötigten Textfeld Einträge gibt es nicht, um den dafür auch nötigen Freiraum zu definieren:
server 192.168.180.0 255.255.255.0 nopool
ifconfig-pool 192.168.180.20 192.168.180.200
- und sicher noch weitere Punkte, die ich noch nicht entdeckt habe / in unserem Setup nicht benötige.
Und ich finde das Verhalten in den Issues anderen und mir gegenüber mit Hinweis auf die Dokus und Formulierungen ähnlich wie "dass das kein Hexenwerk sei" schon etwas "dreist", denn der an sich seit "Jahrzehnten" gut arbeitenden Service wird nach "gut dünken" umgeschrieben und dann den anderen "vorgeworfen" / "hingeklatscht", dass sie das ja selber verbessern könnten, wenn es ihnen "nicht passt" ...
Und dabei nützt die Doku so ziemlich nichts.
Was dort steht, konnte ich auch schon durch Lesen der Konfigurationsdateien und Durchsuchen des Verzeichnisbaums herausfinden und dass, was ich dort nicht "zwischen den Zeilen" finde, steht auch nicht in der angepriesenen Dokumentation.
Und ich konnte bisher auch keine brauchbaren Hinweise finden, wie man sowas ggf. in einer Dev VM testen/debuggen kann (dort wird nur Kernel Debug erklärt) und mit den mir üblichen bekannten Möglichkeiten ist das "simple System" nicht zu debuggen.
Denn alles wird über den "Login" PAM Service geschickt, dann irgendwie durch PHP gequirlt, für das es keine Logging Hooks gibt, dazu hat OpenVPN eigentlich eine eigene Radius Routine, die unabhängig arbeiten müsste, und somit auch das Fehlen der Routen in der User Override Configuration erklären könnte.
Also ist ein Debuggen wenn nur durch sehr aufwendiges und durchaus fehleranfälliges modifzieren innerhalb einer laufenden Instanz ohne Diff und Versionierung umsetzbar.
Da wird es dann doch leider deutlich einfacher, die vom MFA Service mit angebotene MFAvpn Instanz - einem korrekt arbeitenden gepatchten OpenVPN Service - zu verwenden, auch wenn man hier auf den zentrale OpenVPN Service auf der OPNsense ohne explizites Routing verzichten muss.
Ohne hier wirklich kommentieren zu wollen.... es wäre schon sinnvoll wenigstens *unseren* Bugtracker in die Diskussion einzubinden entweder post-op oder proaktiv in dem man einfach mal nen Bugreport macht der gefixt werden kann und dann kann jeder weiter machen mit dem was zu tun ist.
Grüsse
Franco