Hallo Forum,
ich brauche Unterstützung bei der Konfigruation eines OpenVPN Servers.
Während bis 23.1.11 und der alten Konfiguration alles promblemlos und erfreulich stabil lief, gelingt es mir nicht einen VPN Server in den neuen Instanzen zum Laufen zu bringen.
Vielmehr sind nach dem Upgrade auf 23.7.1 auch die alten Server nicht mehr zu erreichen.
Perspektivisch möchte ich alle VPN Server in die neuen Instatanzen übernehmen und die alten Server abschalten.
Hat einer der erfahrenen Nutzer die Zeit und Lust einem unerfahrenen aber lernfreudigen, begeisterten OPNsense- Nutzer zu zeigen welche Einstellungen notwendig sind im Sinnen einer Konfigurationsanleitung?
Was muss ich, wenn überhaupt, bei Bind eintragen, wenn ich dynDNS nutze, etc.?
Freu mich auf Hilfe.
Gruß Bernd
Gute Frage. Ich bleibe bis zur Antwort auf Legacy OpenVPN :)
Kann mir jemand helfen?
Was kann ich tun?
Ich frage auch noch mal im englischen Forum.
Vielen Dank
Kann niemand mit meiner Anfrage etwas anfangen?
Das Forum beobachte ich täglich und habe mehrfach, tausendfach, das Forum durchsucht, um eine Lösung meines Problems zu finden.
Trage ich die nicht statische und vorübergehende IP in den Punkt "Bind" ein, erhalte ich eine Verbindung.
Nun habe ich aber keine statische IP.
Meint der Hinweis in der OPNsense Dokumentation (https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html) "Leave empty to bind to all addresses assigned to this machine or use a loopback address combined with a port forward when the external address is not static." etwa ich muss nach z.B. diesem Tutorial (https://forum.opnsense.org/index.php?topic=34925.0) vorgehen, um den Wegfall der zu beobachtenden Schnittstelle in der "alten" OpenVPN Server Konfiguration zu kompensieren?
Es werden doch nicht alle OPNsense Nutzer, die ein VPN mit OpenVPN einrichten möchten, eine feste IP Adressen haben?
Ich bin ziemlich sicher, dass es eine einfache Anleitung und Lösung gibt, die ich nicht kenne.
OPNsense hat mich in den vergangenen 2 Jahren gelehrt, dass ich das Problem bin und nicht die Firewall.
Was braucht ihr, damit ihr mir antworten und helfen könnt?
moin, dann habe ich mal mitleid mit dir.
was genau willst du für ein OpenVPN Server bauen S2S oder Road warrior.
keine ahnung was genau dein Problem ist, ich habe es schon öfter aufgesetzt (nur mit der Aktuellen Version noch nicht)
Vielen Dank.
Mein Problem ist, dass auch ich mit der alten Version mehrere Road Warriors aufgesetzt habe, die alle problemlos laufen.
Versuche ich die Server auf die neue Instanz zu übertragen oder einen neuen Server einzurichten, so sind mir alle Punkte klar bis auf der Punkt "Bind adress" (siehe Bild oben), also die Stelle wo ich dem Server bekannt gebe, über welche IP die Verbindung erfolgen soll.
Wenn ich also keine statische IP habe, was trage ich dort ein, wenn meine öffentliche IP eine dynDNS Verbindung ist?
Das Feld "Bind adress" leer zu lassen, scheint keine Option zu sein, da ich auf diesem Weg keine Verbindung herstellen kann.
Ich bin jetzt soweit. IP ist bekannt.
Fehler TLS Handshake (siehe Log).
Wo ist mein Fehler?
*Tunnelblick: macOS 12.6.8 (21G725); Tunnelblick 3.8.8c (build 5778); prior version 3.8.7a (build 5770); Admin user
git commit bb7cbce1d218b32d170ae42abd4a70e17d935ccd + uncommitted changes:
?? ../third_party/sources/IOUserEthernetController.h
The Tunnelblick.app process is not being translated (x86_64)
System Integrity Protection is enabled
Model: MacBookPro13,2
Configuration Test
"Sanitized" condensed configuration file for /Users/bernhardunkel/Library/Application Support/Tunnelblick/Configurations/Test.tblk:
Tunnelblick Log:
2023-08-23 08:41:27.726901 *Tunnelblick: macOS 12.6.8 (21G725); Tunnelblick 3.8.8c (build 5778); prior version 3.8.7a (build 5770)
2023-08-23 08:41:28.036976 *Tunnelblick: Attempting connection with Test using shadow copy; Set nameserver = 769; monitoring connection
2023-08-23 08:41:28.037902 *Tunnelblick: openvpnstart start Test.tblk 60493 769 0 1 0 34652464 -ptADGNWradsgnw 2.5.9-openssl-1.1.1v <password>
2023-08-23 08:41:28.055050 *Tunnelblick: openvpnstart starting OpenVPN
2023-08-23 08:41:28.521311 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2023-08-23 08:41:28.521634 OpenVPN 2.5.9 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Aug 1 2023
2023-08-23 08:41:28.521658 library versions: OpenSSL 1.1.1v 1 Aug 2023, LZO 2.10
2023-08-23 08:41:28.522988 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:60493
2023-08-23 08:41:28.523042 Need hold release from management interface, waiting...
2023-08-23 08:41:28.663088 *Tunnelblick: openvpnstart log:
OpenVPN started successfully.
Command used to start OpenVPN (one argument per displayed line):
/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.9-openssl-1.1.1v/openvpn
--daemon
--log /Library/Application Support/Tunnelblick/Logs/-SUsers-Sbernhardunkel-SLibrary-SApplication Support-STunnelblick-SConfigurations-STest.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652464.60493.openvpn.log
--cd /Library/Application Support/Tunnelblick/Users/bernhardunkel/Test.tblk/Contents/Resources
--machine-readable-output
--setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5778 3.8.8c (build 5778)"
--verb 3
--config /Library/Application Support/Tunnelblick/Users/bernhardunkel/Test.tblk/Contents/Resources/config.ovpn
--setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/bernhardunkel/Test.tblk/Contents/Resources
--verb 3
--cd /Library/Application Support/Tunnelblick/Users/bernhardunkel/Test.tblk/Contents/Resources
--management 127.0.0.1 60493 /Library/Application Support/Tunnelblick/Mips/Test.tblk.mip
--management-query-passwords
--management-hold
--script-security 2
--route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
--down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
2023-08-23 08:41:28.674017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:60493
2023-08-23 08:41:28.724428 MANAGEMENT: CMD 'pid'
2023-08-23 08:41:28.724507 MANAGEMENT: CMD 'auth-retry interact'
2023-08-23 08:41:28.724564 MANAGEMENT: CMD 'state on'
2023-08-23 08:41:28.724619 MANAGEMENT: CMD 'state'
2023-08-23 08:41:28.724754 MANAGEMENT: CMD 'bytecount 1'
2023-08-23 08:41:28.725303 *Tunnelblick: Established communication with OpenVPN
2023-08-23 08:41:28.726811 *Tunnelblick: >INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info
2023-08-23 08:41:28.728391 MANAGEMENT: CMD 'hold release'
2023-08-23 08:41:51.587205 MANAGEMENT: CMD 'username "Auth" "Test.VPN"'
2023-08-23 08:41:51.589215 MANAGEMENT: CMD 'password [...]'
2023-08-23 08:41:51.589468 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2023-08-23 08:41:51.591887 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-08-23 08:41:51.591939 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-08-23 08:41:51.592950 MANAGEMENT: >STATE:1692772911,RESOLVE,,,,,,
2023-08-23 08:41:51.645387 TCP/UDP: Preserving recently used remote address: [AF_INET]93.211.XXX.XX:1199
2023-08-23 08:41:51.645469 Socket Buffers: R=[786896->786896] S=[9216->9216]
2023-08-23 08:41:51.645504 UDP link local (bound): [AF_INET][undef]:0
2023-08-23 08:41:51.645520 UDP link remote: [AF_INET]93.211.XXX.XX:1199
2023-08-23 08:41:51.645553 MANAGEMENT: >STATE:1692772911,WAIT,,,,,,
2023-08-23 08:42:51.609725 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-08-23 08:42:51.609838 TLS Error: TLS handshake failed2023-08-23 08:42:51.610266 SIGUSR1[soft,tls-error] received, process restarting
2023-08-23 08:42:51.610392 MANAGEMENT: >STATE:1692772971,RECONNECTING,tls-error,,,,,
2023-08-23 08:42:51.630606 MANAGEMENT: CMD 'hold release'
2023-08-23 08:42:51.630675 MANAGEMENT: CMD 'hold release'
2023-08-23 08:42:51.630795 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2023-08-23 08:42:51.630887 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-08-23 08:42:51.630915 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
This seems to be the issue:
Quote2023-08-23 08:41:28.521311 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Thanks.
I am not sure what to do now and at what side: Server or client.
Since a fundamental change is taking place and I only have a dozen clients to work on, I would like to update the configuration according to the current OpenVPN (client-side and server-side) versions. Do I need a fallback?
The connection documented in the log was made using the instructions in the official and current OPNsense documentation.
Nach mehreren Test und Recherche komme ich zu folgen vorübergehenden Erkenntnissen:
1. Bei der Meldung
Quote2023-08-23 08:41:28.521311 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
handelt es sich um keine Fehlermeldung im engeren Sinne.
(siehe https://hilfe.uni-paderborn.de/VPN_-_Erklaerung_zu_Meldungen_(Log))
Dafür spricht auch
2. Trage ich meine aktuelle IP in "Bind adress" bei der Serverkonfiguration ein, kommt ohne Probleme eine VPN Verbindung zustande. Die Meldung erscheint dennoch.
Das händische Eintragen der wechselnden IP Adresse kann natürlich keine Lösung sein.
Mein Problem bleibt. Wie mache ich dem VPN Server meine nicht statische IP Adresse bekannt. Warum gibt es nicht wie zuvor einen Auswahlpunkt zur WAN Schnittstelle.
Ganz konkret: Was muss ich bei "Bind adress" eintragen?
Nichts - ganz einfach.
Vielen Dank für die Antwort.
Aber "Nichts" funktioniert leider nicht!
Braucht es weitere Informationen?
Welche Einstellungen können verhindern dass der Server Informationen von der WAN Schnittstelle beziehen kann?
PPPOE Telekom VLAN
Vielen Dank
Dann versuch 0.0.0.0 oder 0.0.0.0/0, wenn frei lassen nicht funktioniert. Ich bin nach Doku gegangen bei meiner Antwort und hab es zugegebenermaßen nicht ausprobiert.
Du benutzt Port 1199? Mach doch mal mit "nichts" und mit den beiden Alternativen oben auf der Sense jeweils ein
netstat -na | grep 1199
Wenn da mit "nichts" nichts rauskommt, ist das m.E. ein Bug.
Danke so habe ich etwas zu tun.
Bin derzeit bei der Arbeit und werde es später ausprobieren und rückmelden
Quote from: Patrick M. Hausen on August 24, 2023, 09:43:13 AM
Dann versuch 0.0.0.0 oder 0.0.0.0/0, wenn frei lassen nicht funktioniert. Ich bin nach Doku gegangen bei meiner Antwort und hab es zugegebenermaßen nicht ausprobiert.
Du benutzt Port 1199? Mach doch mal mit "nichts" und mit den beiden Alternativen oben auf der Sense jeweils ein
netstat -na | grep 1199
Wenn da mit "nichts" nichts rauskommt, ist das m.E. ein Bug.
Folgendes zeigte sich in den einzelnen Einstellungen.
Ergebnis mit ,,Nichts":
root@OPNsense:~ # netstat -na | grep 1199
udp46 0 0 *.1199 *.*
Ergebnis mit 0.0.0.0:
root@OPNsense:~ # netstat -na | grep 1199
udp4 0 0 *.1199 *.*
Ergebnis mit 0.0.0.0/0:
wird bereits in der Servereinstellung nicht als gültige IP Adresse akzeptiert
Ergebnis mit 93.21X.2XX.XX3:
root@OPNsense:~ # netstat -na | grep 1199
udp4 0 0 93.21X.2XX.XX3.1199 *.*
Aber dann sind die ersten beiden doch super und das muss funktionieren. Das Problem muss dann woanders liegen.
OK.
Ich hätte in meiner Unkenntnis erwartet, dass dort die IP Adresse der WAN Schnittstelle angezeigt wird.
Gibt es weitere Tests die ich machen kann, um das Problem einzugrenzen?
Hallo an Alle,
gibt es jemanden im Forum der einen OpenVPN Server mit der neuen Instanz und einer dynamischen IP über dynDNS erfolgreich konfiguriert hat?
Mein Problem scheint zu sein, dass der Client keine Antwort vom Server bekommt, da die IP der WAN Schnittstelle nicht bekannt ist.
Konfigurationprobleme der Firewall und der übrigen Servereinstellungen scheinen nicht das Problem zu sein, da die Einrichtung mit dem "alten" Server, aber der identischen Konfiguration zu einer sofortigen Verbindung führen, wie auch die händische Bekanntgabe der derzeit gültigen IP in dem "neuen" Server.
1. Benutz mal tcpdump und schau dir die Pakete auf Port 1199 an.
2. Eine weitere Möglichkeit ist, 127.0.0.1 als Bind Address für den Server einzutragen und eine eingehende NAT Port Forward Regel anzulegen. Eine bewährte Methode, eine stabile Adresse für einen Dienst zu bekommen.
Source: any
Destination: WAN address
Source port: any
Destination port: 1199
Protocol UDP
Redirection target: 127.0.0.1:1199
Associated firewall rule: pass
Nochmals vielen Dank, dass Du Dir Gedanken machst.
Werde es heute Abend nach der Arbeit versuchen.
Möglicherweise ist das Port forwarding eine Lösung des Problems.
Ist es aber im Vergleich zur "alten" Lösung, die auf die WAN Schnittstelle gehört hat, die weniger elegantere und vielleicht auch weniger sichere Lösung?
Bisher bin ich im Internet unsichtbar.
Quote from: b.unkel on August 24, 2023, 05:50:15 PM
Ich hätte in meiner Unkenntnis erwartet, dass dort die IP Adresse der WAN Schnittstelle angezeigt wird.
Das * bedeuted "alle Adressen/Interfaces".
Wieso benutzt du eigentlich Tunnelblick, für macOS gibt es auch OpenVPN Connect:
https://openvpn.net/client-connect-vpn-for-mac-os/
root@OPNsense:~ # tcpdump -v port \1199
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
WAN Port ist igb1, Standardkonfiguration.
Nein exakter vlan01 (parent igb1; TAG 7) PPPOE Telekom
Quote from: vpx23 on August 25, 2023, 06:20:07 PM
Wieso benutzt du eigentlich Tunnelblick, für macOS gibt es auch OpenVPN Connect:
https://openvpn.net/client-connect-vpn-for-mac-os/
Habe Viscosity. Nutze Tunnelblich nur für Testzwecke um ein bisschen Ordnung zu haben.
Quote from: Patrick M. Hausen on August 25, 2023, 11:14:40 AM
2. Eine weitere Möglichkeit ist, 127.0.0.1 als Bind Address für den Server einzutragen und eine eingehende NAT Port Forward Regel anzulegen. Eine bewährte Methode, eine stabile Adresse für einen Dienst zu bekommen.
Source: any
Destination: WAN address
Source port: any
Destination port: 1199
Protocol UDP
Redirection target: 127.0.0.1:1199
Associated firewall rule: pass
Auch mit den Einstellungen kommt keine Verbindung zustande.
Händische IP funktioniert, also VPN Einstellungen stimmen (wenn der Rückschluss zulässig ist)
Quote from: b.unkel on August 25, 2023, 06:21:41 PM
root@OPNsense:~ # tcpdump -v port \1199
Stimmt eigentlich die Syntax?
Muss man hier etwas einstellen (siehe Bild unten?)
Nein, NAT Reflection brauchst du nicht für OpenVPN.
Hier ist dein Fehler beschrieben:
https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/
Hat dein DynDNS die aktuelle IP?
Ist die CA richtig erstellt und steht in der .ovpn-Datei der korrekte DynDNS Host drin?
Vielen Dank für den Link. Den habe ich auch gefunden und die Punkte abgearbeitet. Die IP ist aktuell. Meine alten Server sind verbunden. Auch habe ich den korrekten Eintrag überprüft.
Verweist tcpdump bei der Suche nach Port 1199 nicht nur auf die falsche Schnittstelle? Wird deswegen nicht die externe IP Adresse des Servers vom Client gefunden?
Hast Du eine Verbindung mit dynDNS etablieren können?
Meinst du mit altem Server den OpenVPN-Server? Läuft die neue Instanz auf Port 1199 und die alte Instanz auf Port 1194?
Kannst du bitte mal den OpenVPN Connect Client verwenden und einmal den Log vom alten Server und einmal den Log vom neuen Server zeigen?
Ja ich meine den OpenVPN Server in den man die Schnittstelle aussuchen kann.
Die Server haben jeweils unterschiedliche Ports, die selbstverständlich in den Firewallregeln definiert sind.
Gerne richte ich die beiden Clientkonfiguration in den OpenVPN Connect Client ein. Bin jedoch gerade i meiner Schwiegermutter und werde erst morgen dazu kommen. Berichte aber sobald als möglich!
Danke
Quote from: vpx23 on August 26, 2023, 03:50:54 PM
Meinst du mit altem Server den OpenVPN-Server? Läuft die neue Instanz auf Port 1199 und die alte Instanz auf Port 1194?
Kannst du bitte mal den OpenVPN Connect Client verwenden und einmal den Log vom alten Server und einmal den Log vom neuen Server zeigen?
Anbei die Logs OpenVPN Server legacy und OpenVPN Server new instance.
Scheint es nicht so zu sein, dass der Client mit dem Server der neuen Instanz keine Verbindung aufbauen kann?
Er wartet frustran auf eine Antwort. Der Server hingegen horcht zwar auf alle Schnittstellen, wie netmap ergeben hat, kann aber mit Anfrage nichts anfangen.
Quote
OpenVPN Server Instance (new)
[Aug 27, 2023, 16:52:10] OpenVPN core 3.8 mac x86_64 64-bit built on Jul 26 2023 03:37:17
⏎[Aug 27, 2023, 16:52:10] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Aug 27, 2023, 16:52:10] NOTE: This configuration contains options that were not used:
⏎[Aug 27, 2023, 16:52:10] Feature not implemented (option ignored)
⏎[Aug 27, 2023, 16:52:10] 7 [lport]
⏎[Aug 27, 2023, 16:52:10] Unsupported option (ignored)
⏎[Aug 27, 2023, 16:52:10] 1 [persist-tun]
⏎[Aug 27, 2023, 16:52:10] 2 [persist-key]
⏎[Aug 27, 2023, 16:52:10] 5 [resolv-retry] [infinite]
⏎[Aug 27, 2023, 16:52:10] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:10] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:10] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:10] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:10] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:20] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:20] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:20] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:20] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:20] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:20] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:20] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:30] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:30] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:30] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:30] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:30] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:30] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:30] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:40] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:40] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:40] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:40] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:40] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:40] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:40] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:50] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:50] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:50] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:50] Contacting 93.211.254.93:1199 via UDP
⏎[Aug 27, 2023, 16:52:50] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:50] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:50] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:53:00] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:53:00] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:53:00] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:53:00] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:53:00] EVENT: WAIT ⏎[Aug 27, 2023, 16:53:00] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:53:00] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:53:10] EVENT: CONNECTION_TIMEOUT BYTES_OUT : 3564
PACKETS_OUT : 66
CONNECTION_TIMEOUT : 1
N_RECONNECT : 5
⏎[Aug 27, 2023, 16:53:10] EVENT: DISCONNECTED ⏎[Aug 27, 2023, 16:53:14] Raw stats on disconnect:
BYTES_OUT : 3564
PACKETS_OUT : 66
CONNECTION_TIMEOUT : 1
N_RECONNECT : 5
⏎[Aug 27, 2023, 16:53:14] Performance stats on disconnect:
CPU usage (microseconds): 5891654
Network bytes per CPU second: 604
Tunnel bytes per CPU second: 0
⏎
Quote
OpenVPN Server legacy
[Aug 27, 2023, 16:52:10] OpenVPN core 3.8 mac x86_64 64-bit built on Jul 26 2023 03:37:17
⏎[Aug 27, 2023, 16:52:10] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Aug 27, 2023, 16:52:10] NOTE: This configuration contains options that were not used:
⏎[Aug 27, 2023, 16:52:10] Feature not implemented (option ignored)
⏎[Aug 27, 2023, 16:52:10] 7 [lport]
⏎[Aug 27, 2023, 16:52:10] Unsupported option (ignored)
⏎[Aug 27, 2023, 16:52:10] 1 [persist-tun]
⏎[Aug 27, 2023, 16:52:10] 2 [persist-key]
⏎[Aug 27, 2023, 16:52:10] 5 [resolv-retry] [infinite]
⏎[Aug 27, 2023, 16:52:10] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:10] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:10] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:10] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:10] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:20] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:20] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:20] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:20] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:20] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:20] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:20] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:30] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:30] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:30] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:30] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:30] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:30] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:30] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:40] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:40] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:40] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:40] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:40] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:40] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:40] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:52:50] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:52:50] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:52:50] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:52:50] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:52:50] EVENT: WAIT ⏎[Aug 27, 2023, 16:52:50] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:52:50] Connecting to Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:53:00] Server poll timeout, trying next remote entry...
⏎[Aug 27, 2023, 16:53:00] EVENT: RECONNECTING ⏎[Aug 27, 2023, 16:53:00] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:53:00] Contacting 93.211.XXX.XX:1199 via UDP
⏎[Aug 27, 2023, 16:53:00] EVENT: WAIT ⏎[Aug 27, 2023, 16:53:00] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:53:00] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:53:10] EVENT: CONNECTION_TIMEOUT BYTES_OUT : 3564
PACKETS_OUT : 66
CONNECTION_TIMEOUT : 1
N_RECONNECT : 5
⏎[Aug 27, 2023, 16:53:10] EVENT: DISCONNECTED ⏎[Aug 27, 2023, 16:53:14] Raw stats on disconnect:
BYTES_OUT : 3564
PACKETS_OUT : 66
CONNECTION_TIMEOUT : 1
N_RECONNECT : 5
⏎[Aug 27, 2023, 16:53:14] Performance stats on disconnect:
CPU usage (microseconds): 5891654
Network bytes per CPU second: 604
Tunnel bytes per CPU second: 0
⏎[Aug 27, 2023, 16:55:05] OpenVPN core 3.8 mac x86_64 64-bit built on Jul 26 2023 03:37:17
⏎[Aug 27, 2023, 16:55:05] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Aug 27, 2023, 16:55:05] NOTE: This configuration contains options that were not used:
⏎[Aug 27, 2023, 16:55:05] Feature not implemented (option ignored)
⏎[Aug 27, 2023, 16:55:05] 8 [lport]
⏎[Aug 27, 2023, 16:55:05] Unsupported option (ignored)
⏎[Aug 27, 2023, 16:55:05] 1 [persist-tun]
⏎[Aug 27, 2023, 16:55:05] 2 [persist-key]
⏎[Aug 27, 2023, 16:55:05] 3 [data-ciphers-fallback] [AES-256-CBC]
⏎[Aug 27, 2023, 16:55:05] 6 [resolv-retry] [infinite]
⏎[Aug 27, 2023, 16:55:05] EVENT: RESOLVE ⏎[Aug 27, 2023, 16:55:05] EVENT: WAIT ⏎[Aug 27, 2023, 16:55:05] Contacting 93.211.XXX.XX:1197 via UDP
⏎[Aug 27, 2023, 16:55:05] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
⏎[Aug 27, 2023, 16:55:05] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
⏎[Aug 27, 2023, 16:55:05] EVENT: CONNECTING ⏎[Aug 27, 2023, 16:55:05] Tunnel Options:V4,dev-type tun,link-mtu 1585,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA512,keysize 128,key-method 2,tls-client
⏎[Aug 27, 2023, 16:55:05] Creds: Username/Password
⏎[Aug 27, 2023, 16:55:05] Peer Info:
IV_VER=3.8
IV_PLAT=mac
IV_NCP=2
IV_TCPNL=1
IV_PROTO=990
IV_MTU=1600
IV_CIPHERS=AES-128-CBC:AES-192-CBC:AES-256-CBC:AES-128-GCM:AES-192-GCM:AES-256-GCM:CHACHA20-POLY1305
IV_GUI_VER=OCmacOS_3.4.3-4617
IV_SSO=webauth,openurl,crtext
IV_BS64DL=1
⏎[Aug 27, 2023, 16:55:05] SSL Handshake: peer certificate: CN=VPN Server Zertifikat, 4096 bit RSA, cipher: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
⏎[Aug 27, 2023, 16:55:05] Session is ACTIVE
⏎[Aug 27, 2023, 16:55:05] EVENT: GET_CONFIG ⏎[Aug 27, 2023, 16:55:05] Sending PUSH_REQUEST to server...
⏎[Aug 27, 2023, 16:55:06] Sending PUSH_REQUEST to server...
⏎[Aug 27, 2023, 16:55:06] OPTIONS:
0 [route] [192.168.0] [255.255.255.0]
1 [route] [192.168..0] [255.255.255.0]
2 [dhcp-option] [DNS] [192.168..1]
3 [route] [192.168..1]
4 [topology] [net30]
5 [ping] [10]
6 [ping-restart] [60]
7 [ifconfig] [192.168..14] [192.168..13]
8 [peer-id]
9 [cipher] [AES-256-GCM]
10 [protocol-flags] [cc-exit] [tls-ekm] [dyn-tls-crypt]
11 [tun-mtu] [1500]
12 [block-ipv6]
13 [block-ipv4]
⏎[Aug 27, 2023, 16:55:06] PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: NONE
key-derivation: TLS Keying Material Exporter [RFC5705]
compress: NONE
peer ID: 0
control channel: tls-crypt enabled
⏎[Aug 27, 2023, 16:55:06] TunPersist: short-term connection scope
⏎[Aug 27, 2023, 16:55:06] TunPersist: new tun context
⏎[Aug 27, 2023, 16:55:06] EVENT: ASSIGN_IP ⏎[Aug 27, 2023, 16:55:06] CAPTURED OPTIONS:
Session Name: opnsense.unkeldomain.de
Layer: OSI_LAYER_3
MTU: 1500
Remote Address: 93.211.XXX.XX
Tunnel Addresses:
192.168.22.14/30 -> 192.168..13 [net30]
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv4: yes
Block IPv6: yes
Add Routes:
192.168..0/24
192.168..0/24
192.168..1/32
Exclude Routes:
DNS Servers:
192.168..1
Search Domains:
⏎[Aug 27, 2023, 16:55:06] SetupClient: transmitting tun setup list to /var/run/agent_ovpnconnect.sock
{
"config" :
{
"iface_name" : "",
"layer" : "OSI_LAYER_3",
"tun_prefix" : false
},
"pid" : 25816,
"tun" :
{
"adapter_domain_suffix" : "",
"add_routes" :
[
{
"address" : "192.168..0",
"gateway" : "",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 24
},
{
"address" : "192.168..0",
"gateway" : "",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 24
},
{
"address" : "192.168..1",
"gateway" : "",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 32
}
],
"block_ipv6" : true,
"dns_servers" :
[
{
"address" : "192.168..1",
"ipv6" : false
}
],
"layer" : 3,
"mtu" : 1500,
"remote_address" :
{
"address" : "93.211.XXX.XX",
"ipv6" : false
},
"reroute_gw" :
{
"flags" : 256,
"ipv4" : false,
"ipv6" : false
},
"route_metric_default" : -1,
"session_name" : "mydomain.de",
"tunnel_address_index_ipv4" : 0,
"tunnel_address_index_ipv6" : -1,
"tunnel_addresses" :
[
{
"address" : "192.168..14",
"gateway" : "192.168..13",
"ipv6" : false,
"metric" : -1,
"net30" : true,
"prefix_length" : 30
}
]
}
}
POST unix://[/var/run/agent_ovpnconnect.sock]/tun-setup : 200 OK
{
"iface_name" : "utun5",
"layer" : "OSI_LAYER_3",
"tun_prefix" : true
}
/sbin/ifconfig utun5 down
/sbin/ifconfig utun5 192.168..14 192.168..13 netmask 255.255.255.252 mtu 1500 up
/sbin/route add -net 192.168..12 -netmask 255.255.255.252 192.168..14
add net 192.168..12: gateway 192.168..14
/sbin/route add -net 192.168..0 -netmask 255.255.255.0 192.168..13
add net 192.168..0: gateway 192.168..13
/sbin/route add -net 192.168..0 -netmask 255.255.255.0 192.168..13
route: writing to routing socket: File exists
add net 192.168..0: gateway 192.168..13: File exists
/sbin/route add -net 192.168..1 -netmask 255.255.255.255 192.168..13
add net 192.168..1: gateway 192.168..13
/sbin/route add -net -inet6 2000:: -prefixlen 4 -reject ::1%lo0
add net 2000::: gateway ::1%lo0
/sbin/route add -net -inet6 3000:: -prefixlen 4 -reject ::1%lo0
add net 3000::: gateway ::1%lo0
/sbin/route add -net -inet6 fc00:: -prefixlen 7 -reject ::1%lo0
add net fc00::: gateway ::1%lo0
MacDNSAction: FLAGS=F RD=1 SO=5000 DNS=192.168..1 DOM= ADS=
open utun5 SUCCEEDED
⏎[Aug 27, 2023, 16:55:06] EVENT: CONNECTED Test.VPN@mydomain.de:1197 (93.211.XXX.XX) via /UDP on utun5/192.168..14/ gw=[192.168..13/] mtu=1500⏎[Aug 27, 2023, 16:55:06] Connected via utun5
⏎
Quote
{
"address" : "192.168..1",
"gateway" : "",
"ipv6" : false,
"metric" : -1,
"net30" : false,
"prefix_length" : 32
}
mach doch mal bitte einen screenshot deiner openvpn konfig (nur die neue). lauf deinem post sieht das für mich sehr komisch aus
durch deine ganzen post, ist das jetzt die neue oder die alte konfig?
Er hatte im legacy-Log noch die ersten Zeilen vom new-Log. Etwas verwirrend.
Legacy-Log fängt bei 16:55 Uhr an.
Aber das kommt mir komisch vor:
Legacy
[Aug 27, 2023, 16:55:05] Contacting 93.211.XXX.XX:1197 via UDP
[Aug 27, 2023, 16:55:05] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
[Aug 27, 2023, 16:55:05] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
[Aug 27, 2023, 16:55:05] EVENT: CONNECTING
New
[Aug 27, 2023, 16:52:10] Contacting 93.211.XXX.XX:1199 via UDP
[Aug 27, 2023, 16:52:10] UnixCommandAgent: transmitting bypass route to /var/run/agent_ovpnconnect.sock
{
"host" : "93.211.XXX.XX",
"ipv6" : false,
"pid" : 25816
}
[Aug 27, 2023, 16:52:10] Connecting to [mydomain.de]:1199 (93.211.XXX.XX) via UDP
[Aug 27, 2023, 16:52:20] Server poll timeout, trying next remote entry...
[Aug 27, 2023, 16:52:20] EVENT: RECONNECTING
Bei der alten Methode kontaktiert er über Port 1197, verbindet aber über Port 1199.
Bei der neuen Methode kontaktiert er über Port 1199 und versucht auch über diesen zu verbinden.
Beides ist der gleiche Prozess, also die gleiche Instanz. Kann die gleiche Server-Instanz mehrere Ports haben oder braucht man dafür auch mehrere Instanzen? Oder ist das der Clientprozess?
Quote from: micneu on August 27, 2023, 05:42:41 PM
mach doch mal bitte einen screenshot deiner openvpn konfig (nur die neue). lauf deinem post sieht das für mich sehr komisch aus
durch deine ganzen post, ist das jetzt die neue oder die alte konfig?
Screenshot Konfiguration neuer OpenVPN Server
Auch habe ich die Export Einstellung der Clients hinzugefügt um zu zeigendes ich mich nicht mit den Port vertan habe.
Neue Exportdatei:
Alte Exportdatei
Dann habe ich den Neuen Server deaktiviert.
Und trotzdem zeigt die Log Datei bei des alten OpenVPN Server eine Verbindung mit dem Port 1199 statt wie konfiguriert mit Port 1197.
Hier läuft noch Version 23.4.2 (auf Basis 23.1.11), ich habe dieses "Instance (new)" noch nicht. Wird der parallele Betrieb von der alten Konfiguration und der neuen überhaupt unterstützt, was sagen die Programmierer dazu?
Hast du testweise mal den alten Server deaktiviert?
Der parallele Betrieb wird unterstützt. (https://forum.opnsense.org/index.php?topic=35110.0).
Den alten Server habe ich deaktiviert, was zu keiner Veränderung führte.
Mich interessiert, ob es jemanden schon gelungen ist, die neue Serverinstanz mit dynDNS erfolgreich zu installieren.
Hast du mal probiert beim alten und neuen Server den gleichen Port zu verwenden, damit wir nicht so ein durcheinander mit den Ports haben?
Soweit ich verstanden habe muss für jeden OpenVPN Dienst ein separater Port definiert werden, damit sie parallel betrieben werden können.
Das Port- Durcheinander liegt nicht in der Konfiguration, sondern scheint bei der Herstellung der Verbindung aufgetreten zu sein.
Um einen (Kopier-) Fehler meinerseits auszuschliessen habe ich das mit unterschiedlichen Szenarien getestet und es bleibt bei dem Port- Durcheinander im Log.
Server legacy 1197
Server Instance new 1199.
Quote from: Patrick M. Hausen on August 25, 2023, 11:14:40 AM
1. Benutz mal tcpdump und schau dir die Pakete auf Port 1199 an.
2. Eine weitere Möglichkeit ist, 127.0.0.1 als Bind Address für den Server einzutragen und eine eingehende NAT Port Forward Regel anzulegen. Eine bewährte Methode, eine stabile Adresse für einen Dienst zu bekommen.
Source: any
Destination: WAN address
Source port: any
Destination port: 1199
Protocol UDP
Redirection target: 127.0.0.1:1199
Associated firewall rule: pass
Leider komme ich nicht weiter!
Nach meinen oberflächlichen Verständnis des Problems vermute ich das Problem in meiner Konfiguration der Instance (new) unter dem Punkt "Bind adress".
zu 1. Nach tcpdump (vorausgesetzt meine Syntax ist korrekt) kommt nur eine Rückmeldung von der "falschen" Schnittstelle, der LAN Schnittstelle, und nicht von der WAN Schnittelle (vlan01, TAG 7, auf igb1)
zu 2. Mehrfach in verschiedensten Varianten versucht. Dabei unter anderem auch Server legacy abgeschaltet, gelöscht, um Überschneidungen auszuschliessen, Firewall Regeln nur noch auf ein "Alles- darf- durch" eingestampft etc.
Hat jemand eine funktionierende Konfiguration mit dynDNS mit der neuen Instanz?Ich bin sehr dankbar, wenn diejenige oder derjenige, mir die notwendigen Einstellungen mitteilen könnte, aber auch als Beleg, dass es mit dynDNS funktioniert.
Wenn meine Posts oder Logs missverständlich sind, möge man mir das verzeihen. Ich freue mich auf Tips wie ich das besser und verständlicher machen kann.
Quote from: b.unkel on August 29, 2023, 06:54:56 AM
zu 1. Nach tcpdump (vorausgesetzt meine Syntax ist korrekt) kommt nur eine Rückmeldung von der "falschen" Schnittstelle, der LAN Schnittstelle, und nicht von der WAN Schnittelle (vlan01, TAG 7, auf igb1)
Warum werden die Antworten ausgehend nicht geNATet?
Edit: testest du etwa von deinem LAN aus? Das geht so nicht. Du musst dich zum Test auch von außen verbinden, sonst ist doch klar, dass die OPNsense die Antworten auf direktem Weg wieder ins LAN schickt.Gruß
Patrick
Quote from: Patrick M. Hausen on August 29, 2023, 10:03:22 AM
Edit: testest du etwa von deinem LAN aus? Das geht so nicht. Du musst dich zum Test auch von außen verbinden, sonst ist doch klar, dass die OPNsense die Antworten auf direktem Weg wieder ins LAN schickt.
Gruß
Patrick
Den Test habe ich per ssh auf der OPNsense durchgeführt.
Was heisst in diesem Fall von aussen verbinden?
Mit einem OpenVPN Client über einen völlig anderen Internet-Anschluss, z.B. Mobilfunk, die Verbindung herstellen. Wenn der Client in deinem LAN ist, ist klar, dass Grütze rauskommt.
Werde morgen von der Arbeit aus einen Test starten.
Nochmals vielen Dank für die Hilfe
Gruß
Bernd
Es ist schlicht noch ein BUG beim schreiben der "Client Export" Datei: Wenn [new Instance] im Advanced Modus aufgerufen wird kann man ja u.a. die "Cipher" festlegen [AES GCM 128; AES GCM 256; CHACHAPOLY-1305] und auch die Fallback dazu.
!!Diese werden schlicht nicht als Parameter in die Client Export Datei geschreiben!!
!!Genauso wenig wird der "Fallback" und auch nicht die Kompressionsauswahl beim schreiben der Client Export Datei berücksichtigt!!
@Franco: Bitte nehmt euch dieser Thematik an. Erst nach händischem "data-ciphers CHACHA20-POLY1305" ergänzen in die config Datei funktioniert der (Testtunnel mit eben CHACHA...) zu einer "New Instance" tadellos.
Folgender Stand:
Als aller Erstes: Ich bekomme eine VPN Verbindung aufgebaut mit den Instance new!
Der Test von "aussen" war somit erfolgreich.
Die Ursache für meine Probleme kann ich nicht ins Derail analysieren.
Der Erfolg stellte sich ein, als ich igb1, auf dem mein VLAN für PPPOE läuft, deaktiviert habe.
Die Schnittstelle igb1 war als DHCP konfiguriert und erhielt ihre IP von dem Glasfasermodem der Telekom, damit ich zu Konfigurationszwecken darauf zugreifen konnte - etwas was ich ohnehin nicht nutzte.
Nach Deaktivierung kam sofort eine Verbindung zustande.
An alle die diese Konversation verfolgen:
Mit den neuen Instanzen ist problemlos und wie in der Dokumentation beschrieben eine Verbindung über dynDNS möglich!
Voraussetzung ist natürlich ein funktionierender ddclient, der mit OPNsense als backend mittlerweile zuverlässig läuft. Sicherlich zu Beginn der Umstellung auf 23.7 mein erstes Problem, weshalb kein OpenVPN Dienst funktionierte.
Wie so oft lag das Problem nicht an OPNsense, sondern an mir. Daher auf diesem Weg nochmals vielen Dank für die sehr gute Arbeit des OPNsense- Teams.
Danke aber auch an alle in dieser Konversation, die mir geholfen haben.
Danke