Messages

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.

[--push-reset]

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... ;-)

Secure defaults you mean, see also the notes in passing and reusing headers in https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

This is not about passing / reusing "unsecure" common/all headers (which are by the way passed often by default even you wouldn'dnt have the possibility to use PHPSESSID cookies and other relevant informations)...
its only about the SNI Host header without no communication can be done (Hello "unknown". Are you there?) and was introduced in 2003 so over 20 years ago.
AWS let you pay over 600 USD monthly to get a dedicated CDN IP if you need this SNI-less case.

It takes longer time to "rebuild" each needed services "from ground" with patching if the new system modifies itself within the migration path from pfSense to OPNsense (IPSec, OpenVPN, DHCP and more) ... so testing and public patch requests takes also time to create.
Thats not so funny, too.

Hi,
thanks for the idea. Of course I can add

Code Select Expand

static-challenge "Enter Authenticator Code" 1 at the client which then requests seperately password and OTP. But how does the server know how to handle this information? The server has to be somehow instructed how to concatenate the PWD+CODE.

because it's implemented since 2019
https://github.com/opnsense/core/issues/3290
and fixed again in 2023 after accidently remove when switching to MVC / new script in:

Code Select Expand


$ git show -p b528952260
commit b5289522604b7863a5b3bd8c8a5a21a334b1f59c
Author: Ad Schellevis <ad@opnsense.org>
Date:   Thu Mar 16 10:26:43 2023 +0100

    VPN/OpenVPN - add missing static-challenge parsing, should fix https://forum.opnsense.org/index.php?topic=32939.msg159861#msg159861

diff --git a/src/opnsense/scripts/openvpn/user_pass_verify.php b/src/opnsense/scripts/openvpn/user_pass_verify.php
index 7aebdf282..3fb4be2c8 100755
--- a/src/opnsense/scripts/openvpn/user_pass_verify.php
+++ b/src/opnsense/scripts/openvpn/user_pass_verify.php
@@ -96,6 +96,18 @@ function do_auth($common_name, $serverid, $method, $auth_file)
     if (empty($username) || empty($password)) {
         return "username or password missing ({$method} - {$auth_file})";
     }
+    if (strpos($password, 'SCRV1:') === 0) {
+        // static-challenge https://github.com/OpenVPN/openvpn/blob/v2.4.7/doc/management-notes.txt#L1146
+        // validate and concat password into our default pin+password
+        $tmp = explode(':', $password);
+        if (count($tmp) == 3) {
+            $pass = base64_decode($tmp[1]);
+            $pin = base64_decode($tmp[2]);
+            if ($pass !== false && $pin !== false) {
+                $password = $pin . $pass;
+            }
+        }
+    }
     $a_server = $serverid !== null ? get_openvpn_server($serverid) : null;
     if ($a_server == null) {
         return "OpenVPN '$serverid' was not found. Denying authentication for user {$username}";


The main problem is here only the the "into our default pin+password" which is wrong against default order which is globally password+otp_token ...

[TLS Server Name]

In discussion with Caddy server thread we found out with maintainer that there is since Caddy 1.5.1 the advanced "hidden" parameter TLS Server Name which is documented as:

If the SAN (Subject Alternative Name) of the offered trusted CA certificate or self-signed certificate doesn't match with the IP address or hostname of the Upstream Domain, enter it here. This will change the SNI (Server Name Identification) of Caddy to the TLS Server Name. IP address e.g. 192.168.1.1 or hostname e.g. localhost or opnsense.local are all valid choices. Only if the SAN and SNI match, the TLS connection will work, otherwise an error is logged that can be used to troubleshoot.

Luckily I setup "ages" ago also similar Apache proxies (aand later NGinx proxies) so I remembered that there is a similar ProxyPreserveHost parameter available.
Checking then default behavior of TLSStrictSNI which is On and can here set in Advances Options to Off now I additional searched for ProxyPreserveHost parameter is Off by default and as checked in config it's also explicit set as Off.

After setting it manually to On and reload Web Access service it was running as expected with TLS background service check with correct TLS name in certificate.

The LogLevel option would be nice to have it basically set in general settings but it would be also a good idea to let it set by vhost sometimes in future to avoid useless logging for higher used Web Access proxies if only one backend has to be debugged.
Here one example vhost generated by Web Access GUI:

/usr/local/etc/apache24/Includes/gateway_vhosts.conf:

Code Select Expand

<VirtualHost *:443>
    ServerName host.example.com
    Options -FollowSymLinks
    Options -Indexes
    Options -ExecCGI
    LogLevel warn
    ProxyRequests Off
    SSLProxyEngine On
    SSLProxyCheckPeerName Off

    SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile    /var/etc/apache_b465c420-6703-481e-acab-6a91a06e08bf.pem
    SSLCertificateKeyFile /var/etc/apache_b465c420-6703-481e-acab-6a91a06e08bf.key

    # https://wiki.mozilla.org/Security/Server_Side_TLS
    # TLS Intermediate configuration
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
    SSLHonorCipherOrder     off
    SSLCompression          off
    SSLSessionTickets       off
    SSLOptions              +StrictRequire

    SSLUseStapling          On


    <Location "/">
        ProxyPreserveHost Off
        ProxyPass "balancer://64e6acb1-3b46-4006-9a46-a5e582df6f24/"
        ProxyPassReverse "balancer://64e6acb1-3b46-4006-9a46-a5e582df6f24/"
    </Location>

    Header always merge Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
    # Add security and privacy related headers
    Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
    Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
    Header set Referrer-Policy "strict-origin"
    Header set X-Frame-Options: "deny"
    SetEnv modHeadersAvailable true


</VirtualHost>
<Proxy balancer://555f9699-86b5-4214-a027-437004b5f9d7>
    BalancerMember https://10.30.2.167
</Proxy>

Would be nice to get the 5 failure points fixed/implemened and maybe also the addition 3 points sometime in future when possible.

[fehlerhaft umgeschrieben/verwendet]

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) unerwartet zügig behoben bzw. haben ihn bei einem weiteren Patches dieses Jahr wieder erzeugt gem Kommentaren in Redmine #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:

Code Select Expand

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.

If you have before also OpenVPN used from your hosted VM it is maybe an idea to use an OpenVPN tunneln instead or a wireshark one so you don't have need for external services?

There should be also enough howtos for this setup available and you have the possibility to configure/restrict traffic on hosted site.
For instance you can use an "stonage" service like rinetd which can offer Ports similara to xinetd on hosted side but tunnels it to a different IP address (TCP only).

Wenn eine NAT Regel von OpenVPN=> SIP Netz vorhanden ist, kann die nicht "reverse" in die andere Richtung funktionieren ohne Aktive NAT Verbindung des Clients zur PBX, da die FW selber nur die Session kennt und keine PBX<=> Client Zuordnungen.
Daher muss auch auf eine hohe "moderate" TTL geachtet werden und kurze Registrierungs-Intervalle am Client.

Und durch die NAT Regel wird in der Regel ja die entsprechende FW Regel angelegt, die dann auch für die "Antwortpakete" gültig ist (bzw. was auch noch zu der Session gehört)

Wenn möglich, würde ich eher das NAT abschaffen, da dies über allgemeines Routing der FW regelbar ist.

OK, die neue Option "TLS Server Name" neben der schon gelesenen "TLS Insecure Skip Verify" Option eben nach einem Update der Test OPNsense VM gefunden (neu zumindest seit 1.5.2) ...

Und erfreulicherweise auch nicht in den Advanced Options "versteckt", so dass der unbedarfte User das dann intuitiv sogar entsprechend erfolgreich konfigurieren kann  ;D 👍

yes, automatic resolver works like a charm after updating version to latest repository version ;-)

Code Select Expand

***GOT REQUEST TO SYNC***
Currently running OPNsense 24.1.6 at Sun Apr 21 15:52:36 UTC 2024
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'os-wireguard' have been found in the repositories
Checking integrity... done (0 conflicting)
Nothing to do.
***DONE***

changing nothing...
But luckily the ~ "reset local differences" does:

Code Select Expand


***GOT REQUEST TO RESYNC***
Currently running OPNsense 24.1.6 at Sun Apr 21 15:54:28 UTC 2024
Unregistering plugin: os-wireguard
***DONE***

... where btw the select box disappeared after successful run so nobodoy knows about this feature by default and I am also not the correct button labeling afterwards.

Thx for the hint; maybe such information can be given in info popup window in future.

Stays maybe the possibility for deletion of by plugins unreferenced packages itself.

as you alreaday found out there are many articales and videos about implementing such tunnel.
Important for pfSense/OPNsense is still the opening of the tunnel for needed port 80/443 to let traffic in which can be forgotten for normal routing usage.

Did you allso found this direct configuration guide?
https://tailscale.com/kb/1097/install-opnsense

For "Packages" it's maybe intentionally not setup because usually they are dependencies of the plugins.
But if not it could be sometimes of interest to remove them manual over GUI (and maybe there could be a function to fetch such rare packages by URL?).

With this update the OS-WireGuard plugin is somehow also a candidate which cannot be removed from list of installed plugins.
I guess because it's now included in main OPNsense core because I can see it still within VPN section ?

Ja für Community dann sicher eine gute Alternative.
Hatte mir die neueste Version nur kurz in einer Test VM lokal auf Notebook angesehen ohne groß zu testen und war bei kurzer Recherche auch erstaunt, dass der schon über 8 Jahre entwickelt wird, da man von ihm kaum was gehört hat.

Wenn möglich wäre, sollte man - wie auch noch für OpenWAF fehlend - das LogLevel definieren können, da hier wirkich ohne funktionierende Glaskugel sonst kein Debugging möglich ist.
Die "HTTP Access Log" Option je Proxy Domain ist allgemein aber schon ein guter Anfang ^^

Ich konnte anhand der Logs nicht den Fehler erkennen... immerhin habe ich, wie vorab vermutet, durch Deaktivieren der TLS Funktion im Backend feststellen können, dass es irgendein Problem mit der TLS Kommunikation geben muss:

<11>1 2024-04-15T17:30:57+02:00 fw01.local.example.com caddy - - [meta sequenceId="3"] "error","ts":"2024-04-15T15:30:57Z","logger":"http.log.access.b9770f33-cc73-4431-8647-11a8b40c9409","msg":"handled request","request":{"remote_ip":"79.140.126.XX","remote_port":"6598","client_ip":"79.140.126.XX","proto":"HTTP/2.0","method":"GET","host":"uhd.example.com","uri":"/","headers":{"User-Agent":["curl/8.6.0"],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"uhd.example.com"}},"bytes_read":0,"user_id":"","duration":0.001070664,"size":0,"status":502,"resp_headers":{"Alt-Svc":["h3=\":443\"; ma=2592000"],"Server":["Caddy"]}}

<11>1 2024-04-15T17:49:04+02:00 fw01.local.example.com caddy - - [meta sequenceId="8"] "error","ts":"2024-04-15T15:49:04Z","logger":"http.log.access.b8bf171c-cce8-4285-b4ff-7e1c34c41bbd","msg":"handled request","request":{"remote_ip":"79.140.126.XX","remote_port":"60820","client_ip":"79.140.126.XX","proto":"HTTP/2.0","method":"GET","host":"akeneo.example.com","uri":"/","headers":{"User-Agent":["curl/8.6.0"],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"akeneo.example.com"}},"bytes_read":0,"user_id":"","duration":0.004570455,"size":0,"status":502,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}

<14>1 2024-04-15T17:52:31+02:00 fw01.local.example.com caddy - - [meta sequenceId="1"] "info","ts":"2024-04-15T15:52:31Z","logger":"http.log.access.b9770f33-cc73-4431-8647-11a8b40c9409","msg":"handled request","request":{"remote_ip":"79.140.126.XX","remote_port":"10714","client_ip":"79.140.126.XX","proto":"HTTP/2.0","method":"GET","host":"uhd.example.com","uri":"/","headers":{"User-Agent":["curl/8.6.0"],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"uhd.example.com"}},"bytes_read":0,"user_id":"","duration":0.066035783,"size":5875,"status":200,"resp_headers":{"Last-Modified":["Mon, 28 Aug 2023 09:39:57 GMT"],"Vary":["Accept-Encoding"],"Server":["Caddy","Apache/2.4.38 (Debian)"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Etag":["\"16f3-603f87a3ca4bc-gzip\""],"Accept-Ranges":["bytes"],"Content-Type":["text/html"],"Date":["Mon, 15 Apr 2024 15:52:31 GMT"]}}

Ich gehe davon aus, dass Caddy das gleiche Problem wie der Apache hat, und das vom jeweiligen Backend Server korrekt angebotene TLS Zertifkat mit dem CN/SAN: "*.example.com" mit den jeweiligen aufgerufenen Backend IP Adressen 10.30.x.x anstatt des aufgerufenen SNIs vergleicht und daher zur fehlerhaften logischen Feststellung kommt, dass diese nicht matchen...

Bitte bedenken, dass bei FreeBSD der Mix von VLAN und Untagged nicht besonders gut funktioniert - bei Unifi ist das aber eher der Regelfall.

Gerade die Unifi Switche haben das Problem, kein Tag 1 nutzen zu können, was ein ziemliches initiales Konfigurationsproblem für die "Trunks" zu den OPNsenses war... 

Bei ONPsense funktionidert bei uns jetzt das lagg0 für VLAN 1 (was ich zuerst an einer sehr alten CISCO als lagg0_vlan1 konfiguriert hatte) und lagg0_vlanXXX für das jeweilige VLAN Tqg sehr gut.

Hi, eigentlich sollte die Telefonanlage auch ohne NAT den VPN Client "finden" können, denn die Default Route liegt im allgemeinen ja auf der Firewall IP und damit weiss die Firewall - sofern die Ports entsprechend geöffnet sind, wie von dem einen zum anderen Netz gerouted werden muss, um eine Kommunikation zu ermöglichen.

Bei unserer noch verwendeten pfSense ist aber unbekannterweise ebenfalls ein NAT eingerichtet worden, bei dem - erstaunlicherweise nur bei ein Teil der Mitarbeiter - ebenso ein solches Problem auftritt.

Ich hatte das mit dem sehr guten und hier auch hilfreichen PhonerLite ausprobiert (größerer Bruder wäre Phoner), bei dem man die Diagnose aktivieren und so die Kommunikation zwischen VPN Client und Telefonanlage mitlesen kann.

In diesen Headern war der Client lt. Status der Telefonanlage nicht mit seiner IP, sondern der der FW angemeldet;
Frage ist dann natürlich, wie die Telefonanlage wissen wollte, auf welchem der x Clients sie Anfragen zustellen soll, zumindest wenn die UDP Session TTL zu groß ist
Dazu gab es hier schon Fragen/Lösung:
Man muss die FW irgendwo in den Fiirewall Advanced Settings auf "Moderate" states setzen, damit die UDP TTL länger ist.
Und man sollte zusätzlich die beim Client eingestellte Registrationsintervalle überprüfen und ggf. auch verringern, damit diese z.B. alle 60 bis spätestens 90s die UDP Verbindung refreshen und somit auch die UDP Session in der Firewall.