Moin zusammen,
baue gerade eine neue OpnSense auf.
Dabei habe ich so meine Probleme mit der "neuen" Konfig für OpenVPN, Instances und co sind leider nicht gut dokumentiert.
Nachdem ich dann irgendwie einen Tunnel hin bekommen habe, stellte ich fest, dass das Widget den Tunnel nicht anzeigt (ipg).
Kam das bei euch auch schon vor?
Hat jemand eine Idee, was da falsch läuft?
Moin,
Geht es um Clients (S2S) oder einen Server mit Clients? Und die 24.7.1 ist drauf?
Grüsse
Franco
Kann ich folgende Informationen haben?
https://192.168.1.1/api/openvpn/service/search_sessions
Was wird da zurückgegeben? Die IP Adresse mit der von deiner OPNsense ersetzen.
Wenn irgendwas geheimes in der Ausgabe steht, vor dem posten mit "REDACTED" ersetzen.
Jub, das ist eine 24.7.1, von einer 23 hoch migriert.
{"total":1,"rowCount":1,"current":1,"rows":[{"status":"ok","type":"server","id":"38018d6d-0204-43cb-b280-b5a87113e94c_1Scrambled:57684","description":"Open-VPN-Service","common_name":"UNDEF","real_address":"Scrambled:57684","virtual_address":"192.168.200.2","virtual_ipv6_address":"","bytes_received":"185289","bytes_sent":"75106","connected_since":"2024-08-12 15:43:51","connected_since__time_t_":"1723470231","username":"VPN-Test","client_id":"22","peer_id":"1","data_channel_cipher":"AES-256-GCM","is_client":true}]}
unter /ui/openvpn/status bekomme ich auch eine Anzeige ...
sehr merkwürdig
gerade auf eine "alte" OS geschaut .. schaut ebenfalls merkwürdig aus
Kommando zurück ...
bei der anderen OS hat ein Kollege alle Profile wieder zurück geschwenkt, weil die User von der TOTP App genervt waren und sie sich nicht getraut haben mir das zu sagen :o
Eigentlich war es genau anders herum geplant (alle auf 2FA) .... wenn die nun jemand aufs Korn nimmt, selbst Schuld!
Also hat sich das hier erledigt? Ich verstehe nicht ganz.
Leider zeigt das Widget immer noch nichts an.
Nächster Step wäre die OpenVPN Konfig zu löschen und händisch neu ein zu tragen.
Neustarts der Dienste und Booten haben bisher nichts geändert.
Ich teste den API Output den du gesendet hast morgen mit dem Widget.
"Ich teste den API Output den du gesendet hast morgen mit dem Widget."
Das wäre super, danke.
Ich will mal versuchen ein altes Backup wieder auf 24.1 rauf zu ziehen .. evtl liegts am Upgrade ?
Ich denke es liegt hier dran:
"common_name":"UNDEF"
Hat das Zertifikat für den exportierten Client ein "Common Name" definiert? Hier kann z.b. ein Username im Zertifikat stehen.
Also generiere ein neues Client Zertifikat in dem für den User ein Common Name steht, z.b. "User01" und teste dann nochmal.
okay, das versuche ich mal - vielen Dank für den Tip!
Irgendwie hab ich mich noch nicht so an die neue GUI gewöhnt.
Neue Optik, neue Begriffe ... leider ist die Doku noch nicht bei "neu" angekommen - stochere viel im Nebel.
Da ist jemand der Hilft echt Gold wert. danke.
Hey Monviech,
es läuft ...
Habe die Instance neu gebaut, den User neu, neu exportiert und siehe da - der Client wird jetzt angezeigt.
Dafür steht jetzt Server-Connections auf "undefined" ... also schmeiß ich das Widget lieber raus, sonst irritiert das wieder irgendwen.
Wo ist denn die Dokumentation noch nicht neu?
https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html
als Beispiel:
gerade das Redirect gateway wirft nicht nur bei mir Fragen auf.
da gibt es viel mehr Möglichkeiten als nur "default" oder nichts - wie unter https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html
Da würde ich schon zu jeder Option zumindest einen Hinweis erwarten wozu diese gut ist.
Ab einem gewissen Punkt muss man zwangsläufig auch die Upstream Doku hinzuziehen wenn man nicht weiss was man tut oder welche Option man nun braucht.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
Grüsse
Franco
bisher war die OpenVPN Doku nicht sehr hilfreich - aber dafür hat man ja jetzt alles Umgestellt:
Doku zum Redirect Gateway:
--redirect-gateway flags
Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option.
This option performs three steps:
Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.
Delete the default gateway route.
Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).
When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.
Option flags:
local
Add the local flag if both OpenVPN peers are directly connected via a common subnet, such as with wireless. The local flag will cause step (1) above to be omitted.
autolocal
Try to automatically determine whether to enable local flag above.
def1
Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.
bypass-dhcp
Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).
bypass-dns
Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).
block-local
Block access to local LAN when the tunnel is active, except for the LAN gateway itself. This is accomplished by routing the local LAN (except for the LAN gateway address) into the tunnel.
ipv6
Redirect IPv6 routing into the tunnel. This works similar to the def1 flag, that is, more specific IPv6 routes are added (2000::/4, 3000::/4), covering the whole IPv6 unicast space.
!ipv4
Do not redirect IPv4 traffic - typically used in the flag pair ipv6 !ipv4 to redirect IPv6-only.