8
Frage zu OpenVPN Protokolleintrag
Hallo Leute,
ich habe eine Frage bezüglich einem Protokoll-Eintrag bei einer OPNsense (Verständnisfrage).
Wir haben gestern eine neue OpenVPN Site2Site Standortverknüpfung mit zwei OPNsense Firewalls in Betrieb genommen (Peer-to-Peer mit TLS Authentication & encryption). Soweit funktioniert alles, Vor den Firewalls macht eine aktuelle FritzBox die Einwahl ins Internet. Edit: Der Road-Warrior-VPN ist auch mit TLS Authentication & encryption und zusätzlich mit Benutzername und Kennwort konfiguriert.
Zunächst eine kleine Übersicht:
Standort A:
Standort B:
Ich habe nun in den OpenVPN Logs aber ein paar seltsame Protoklleinträge gesehen.
Im VPN-Protokoll beim Standort A sehe ich z.B. so einen Eintrag (ich gehe davon aus, dass der openvpn_server1 der S2S-Server ist):
Zu dieser Uhrzeit kann ich einen Internetausfall von Standort A verzeichnen. Soweit so verständlich; die Verbindung wird neu aufgebaut und die TSL-Aushandlung schlägt ein paar Sekunden fehl und wird danach wieder erfolgreich aufgebaut.
Ich sehe aber noch folgende Einträge (ich gehe davon aus, dass der openvpn_server2 der RW-Server ist):
Aufgrund der öffentlichen IP, die von z.B. abuseipdb.com als 100% Schadhaft eingeschätzt wird (https://www.abuseipdb.com/check/205.210.31.89), gehe ich davon aus, dass es sich dabei um "normale" automatisierte Angriffsversuche handelt, habe ich damit Recht? Oder besteht hier Handlungsbedarf oder macht die OPNsense schlicht ihren Job?
Vielen Dank im Voraus
MfG
ich habe eine Frage bezüglich einem Protokoll-Eintrag bei einer OPNsense (Verständnisfrage).
Wir haben gestern eine neue OpenVPN Site2Site Standortverknüpfung mit zwei OPNsense Firewalls in Betrieb genommen (Peer-to-Peer mit TLS Authentication & encryption). Soweit funktioniert alles, Vor den Firewalls macht eine aktuelle FritzBox die Einwahl ins Internet. Edit: Der Road-Warrior-VPN ist auch mit TLS Authentication & encryption und zusätzlich mit Benutzername und Kennwort konfiguriert.
Zunächst eine kleine Übersicht:
Standort A:
OpenVPN S2S Server
OpenVPN RW Server
WAN-IP: 192.168.2.254
LAN-IP: 192.168.1.1Standort B:
OpenVPN S2S Client
WAN-IP: 192.168.4.254
LAN-IP: 192.168.3.254Ich habe nun in den OpenVPN Logs aber ein paar seltsame Protoklleinträge gesehen.
Im VPN-Protokoll beim Standort A sehe ich z.B. so einen Eintrag (ich gehe davon aus, dass der openvpn_server1 der S2S-Server ist):
2023-07-12T23:30:38 Error openvpn_server1 <öffentliche_IP_Standort_B>:40082 TLS Error: TLS handshake failed
2023-07-12T23:30:38 Error openvpn_server1 <öffentliche_IP_Standort_B>:40082 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-07-12T23:29:37 Error openvpn_server1 <öffentliche_IP_Standort_B>:40082 TLS Error: reading acknowledgement record from packet Zu dieser Uhrzeit kann ich einen Internetausfall von Standort A verzeichnen. Soweit so verständlich; die Verbindung wird neu aufgebaut und die TSL-Aushandlung schlägt ein paar Sekunden fehl und wird danach wieder erfolgreich aufgebaut.
Ich sehe aber noch folgende Einträge (ich gehe davon aus, dass der openvpn_server2 der RW-Server ist):
2023-07-13T10:02:31 Error openvpn_server2 tls-crypt unwrap error: packet too short
2023-07-13T01:02:21 Error openvpn_server2 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:205.210.31.89:54658 (via ::ffff:192.168.2.254%igb0)Vielen Dank im Voraus
MfG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7835926090
Url: https://administrator.de/forum/frage-zu-openvpn-protokolleintrag-7835926090.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
8 Kommentare
Neuester Kommentar
Da versuchen Leute mit Portscans das Internet abzufrasen und OpenVPN-Instanzen zu finden.
Wenn du dich dagegen schützen willst, kannst du einen TA-Key erstellen und verteilen (ein gemeinsamer Key für alle).
Dann müssen ausnahmslos alle Pakete mit diesem Key signiert sein, sonst ignoriert OpenVPN das und stellt sich taub.
Damit verschwinden nornalerweise auch diese Logeinträge, werden dann aber eventuell ersetzt durch "HMAC authentication failed"-Fehler. Aber dann weiß man woran man ist.
Wenn du dich dagegen schützen willst, kannst du einen TA-Key erstellen und verteilen (ein gemeinsamer Key für alle).
Dann müssen ausnahmslos alle Pakete mit diesem Key signiert sein, sonst ignoriert OpenVPN das und stellt sich taub.
Damit verschwinden nornalerweise auch diese Logeinträge, werden dann aber eventuell ersetzt durch "HMAC authentication failed"-Fehler. Aber dann weiß man woran man ist.
1
Zitat von @LordGurke:
Da versuchen Leute mit Portscans das Internet abzufrasen und OpenVPN-Instanzen zu finden.
Wenn du dich dagegen schützen willst, kannst du einen TA-Key erstellen und verteilen (ein gemeinsamer Key für alle).
Dann müssen ausnahmslos alle Pakete mit diesem Key signiert sein, sonst ignoriert OpenVPN das und stellt sich taub.
Damit verschwinden nornalerweise auch diese Logeinträge, werden dann aber eventuell ersetzt durch "HMAC authentication failed"-Fehler. Aber dann weiß man woran man ist.
Da versuchen Leute mit Portscans das Internet abzufrasen und OpenVPN-Instanzen zu finden.
Wenn du dich dagegen schützen willst, kannst du einen TA-Key erstellen und verteilen (ein gemeinsamer Key für alle).
Dann müssen ausnahmslos alle Pakete mit diesem Key signiert sein, sonst ignoriert OpenVPN das und stellt sich taub.
Damit verschwinden nornalerweise auch diese Logeinträge, werden dann aber eventuell ersetzt durch "HMAC authentication failed"-Fehler. Aber dann weiß man woran man ist.
Hi,
das ging ja schnell, danke für deine Antwort. Ich hatte eben noch die RW-Einstellungen im Beitrag hinzugefügt, beim RW nutzen wir auch TLS Authentication & encryption und zusätzlich mit Benutzername und Kennwort. Daher wurde dort auch ein entsprechender TLS Key erstellt und mit der OVPN-Datei exportiert. Die genannten Fehler resultieren also daraus, dass OpenVPN die Pakete ignoriert und die OPNsense das als unwrap error: packet too short loggt?
OpenVPN Site2Site Standortverknüpfung
Warum man sich sowas antut und immer noch schlecht skalierende S2S VPNs damit aufsetzt ist in Zeiten von IPsec oder Wireguard völlig unverständlich. Ziemlich von gestern und Verschwendung von Resourcen und TLS Probleme eleminiert das per se auch.Auch dem Road Warrier kann man mit der OPNsense die bordeigenen VPN Clients problemlos nutzbar machen um die Frickelei mit unnützer VPN Client Software zu vermeiden.
VPN technisches Neandertal oder fehlendes KnowHow oder beides...aber egal.
Ein Bild sagt mehr als 1000 Worte:
Sorry, aber Wireguard ist das übelste Stück VPN mit dem ich jemals gearbeitet habe. Das habe ich sogar mit IPsec in den Neunzigern besser gesehen.
Seit ich gesehen habe, dass das von einer Consulting-Bude entwickelt wird glaube ich auch, dass das pure Absicht ist: Schlimme Software verbreiten, damit Leute den Support kaufen.
VPN-Verbindung zu einem DNS-Namen mit mehreren IP-Adressen? Mit IPsec oder OpenVPN kein Problem, aber Wireguard? Wenn auf der ersten gelieferten IP kein Handshake zustande kommt, dann bleibt das auch so.
DNS-Name hat einen A- und einen AAAA-Record? Dann findet kein Failover nach IPv4 statt, wenn IPv6-Konnektivität nicht funktioniert. Garantiert auch wegen dem dummen Umgang mit DNS.
Mehrere Gegenstellen mit IP-Literals angeben? Schlicht nicht vorgesehen.
Vom fehlenden Config-Push auf den Client ganz zu schweigen. Es müssen irgendwann andere DNS-Server verwendet werden? Wir müssen plötzlich ein zusätzliches Netz ins VPN routen? Der Client soll eine andere IP bekommen? Dann erstmal überall die Configs austauschen, weil dynamisch vom Server aus konfigurieren kannst du das nicht! Was bei Onkel Günter, der von Helgoland aus auf die FritzBox im Keller der Doppelhaushälfte in Bochum-Stiepel zugreifen will durchaus akzeptabel ist, skaliert halt nicht, wenn du das bei 100 Usern machen musst.
Und dass da bessere Geschwindigkeit bei rumkommt, wenn das Protokoll nativ im Kernel läuft, ist wenig überraschend. Wenn Wireguard für eine Plattform nicht nativ im Kernel enthalten ist fällt dieser Geschwindigkeitsvorteil deutlich geringer aus. Du kannst ja mal die Geschwindigkeiten von OpenVPN und Wireguard auf einem Android-Gerät vergleichen - da läuft beides im Userspace.
Aber wer ernsthaft Wireguard für eine Anwendung im Business-Bereich empfiehlt, weiß es vermutlich nicht besser oder steht auf Schmerzen. Oder, um deine Worte zu benutzen: "Fehlendes Know-How".
OpenVPN ist nicht perfekt, das weiß ich selbst, aber nur höhere Geschwindigkeit auf manchen Plattformen allein kann ja auch nicht die Entschuldigung für alles sein.
Seit ich gesehen habe, dass das von einer Consulting-Bude entwickelt wird glaube ich auch, dass das pure Absicht ist: Schlimme Software verbreiten, damit Leute den Support kaufen.
VPN-Verbindung zu einem DNS-Namen mit mehreren IP-Adressen? Mit IPsec oder OpenVPN kein Problem, aber Wireguard? Wenn auf der ersten gelieferten IP kein Handshake zustande kommt, dann bleibt das auch so.
DNS-Name hat einen A- und einen AAAA-Record? Dann findet kein Failover nach IPv4 statt, wenn IPv6-Konnektivität nicht funktioniert. Garantiert auch wegen dem dummen Umgang mit DNS.
Mehrere Gegenstellen mit IP-Literals angeben? Schlicht nicht vorgesehen.
Vom fehlenden Config-Push auf den Client ganz zu schweigen. Es müssen irgendwann andere DNS-Server verwendet werden? Wir müssen plötzlich ein zusätzliches Netz ins VPN routen? Der Client soll eine andere IP bekommen? Dann erstmal überall die Configs austauschen, weil dynamisch vom Server aus konfigurieren kannst du das nicht! Was bei Onkel Günter, der von Helgoland aus auf die FritzBox im Keller der Doppelhaushälfte in Bochum-Stiepel zugreifen will durchaus akzeptabel ist, skaliert halt nicht, wenn du das bei 100 Usern machen musst.
Und dass da bessere Geschwindigkeit bei rumkommt, wenn das Protokoll nativ im Kernel läuft, ist wenig überraschend. Wenn Wireguard für eine Plattform nicht nativ im Kernel enthalten ist fällt dieser Geschwindigkeitsvorteil deutlich geringer aus. Du kannst ja mal die Geschwindigkeiten von OpenVPN und Wireguard auf einem Android-Gerät vergleichen - da läuft beides im Userspace.
Aber wer ernsthaft Wireguard für eine Anwendung im Business-Bereich empfiehlt, weiß es vermutlich nicht besser oder steht auf Schmerzen. Oder, um deine Worte zu benutzen: "Fehlendes Know-How".
OpenVPN ist nicht perfekt, das weiß ich selbst, aber nur höhere Geschwindigkeit auf manchen Plattformen allein kann ja auch nicht die Entschuldigung für alles sein.
2
Da hast du natürlich Recht. Nicht das du das missverstehst, das sollte auch keinesfalls ein Plädoyer für WG sein. Allein schon das gruselige Drama der WG Implementation in der Fritzbox spricht Bände. Also full ACK was den Business Einsatz angeht...
Der TO wäre deutlich besser gefahren das S2S mit einer klassischen IKEv2 S2S Konfiguration und auch die RoadWarrior Lösung mit IKEv2 zusammen zu lösen in der OPNsense. Aber jedem Tierchen eben halt sein Pläsierchen...
Der TO wäre deutlich besser gefahren das S2S mit einer klassischen IKEv2 S2S Konfiguration und auch die RoadWarrior Lösung mit IKEv2 zusammen zu lösen in der OPNsense. Aber jedem Tierchen eben halt sein Pläsierchen...
Zitat von @aqui:
Der TO wäre deutlich besser gefahren das S2S mit einer klassischen IKEv2 S2S Konfiguration und auch die RoadWarrior Lösung mit IKEv2 zusammen zu lösen in der OPNsense. Aber jedem Tierchen eben halt sein Pläsierchen...
Der TO wäre deutlich besser gefahren das S2S mit einer klassischen IKEv2 S2S Konfiguration und auch die RoadWarrior Lösung mit IKEv2 zusammen zu lösen in der OPNsense. Aber jedem Tierchen eben halt sein Pläsierchen...
Hauptsächlich Variante 3: kundenübergreifende Standards. Ein bisschen Variante 2: Bietet IPSec AD Authentifizierung auf Userbasis? Was ist wahrscheinlicher, dass IPSec oder OpenVPN in Gast-Netzen, Hotspots usw freigegeben ist?
Meine Erfahrungen mit IPSec waren bisher: "entweder es geht oder es geht nicht". Auch wenn es theoretisch ein Standard geben soll funktioniert es manchmal einfach nicht. OpenVPN habe ich bisher immer zum Laufen gebracht.
Von Wireguard halte ich mich lieber fern.
MfG
Bietet IPSec AD Authentifizierung auf Userbasis?
Ein bisschen eine sinnfreie Frage wenn es um den Windows onboard VPN Client geht, oder? Mehr "Standard" geht ja nun nicht. Zumal er auch bei Apple und allen Smartphones, Pads, Tablets onboard VPN Standard ist. OpenVPN sucht man da bekanntlich vergebens.Eine bessere Integration ins Betriebssystem inkl. AD Userauth und GPO Fähigkeit wirst du ja wohl kaum finden! Ansonsten hätte Microsoft ja grundsätzlich etwas falsch gemacht.
Was ist wahrscheinlicher, dass IPSec oder OpenVPN in Gast-Netzen, Hotspots usw freigegeben ist?
Vermutlich, denn es ist einfacher SSL basierte VPN Protokolle mit singulären Ports zu blocken. Sowas ist aber reine Kaffeesatzleserei.Meine Erfahrungen mit IPSec waren bisher: "entweder es geht oder es geht nicht".
Gilt ja letzlich für alle VPN Protokolle und Verfahren. Wenn man es falsch macht klappt es eben nicht. Einfache Logik! Zitat von @aqui:
Eine bessere Integration ins Betriebssystem inkl. AD Userauth und GPO Fähigkeit wirst du ja wohl kaum finden! Ansonsten hätte Microsoft ja grundsätzlich etwas falsch gemacht.
Hi,Bietet IPSec AD Authentifizierung auf Userbasis?
Ein bisschen eine sinnfreie Frage wenn es um den Windows onboard VPN Client geht, oder? Mehr "Standard" geht ja nun nicht. Zumal er auch bei Apple und allen Smartphones, Pads, Tablets onboard VPN Standard ist. OpenVPN sucht man da bekanntlich vergebens.Eine bessere Integration ins Betriebssystem inkl. AD Userauth und GPO Fähigkeit wirst du ja wohl kaum finden! Ansonsten hätte Microsoft ja grundsätzlich etwas falsch gemacht.
ich habe eben dein IPSec Client Tutorial überflogen und ich werde das mal bei mir privat testen. Wie es aussieht, kann man bei User Authentication vermutlich auch ldap wählen? Was mir nicht gefällt ist der manuelle Import der CA, aber das lässt sich bei einem AD-gejointen Computer ja auch per GPO erledigen. Blöd nur bei Nicht-AD Computern, aber gleiche Nervigkeit hat man auch mit dem OpenVPN Client.
Zitat von @aqui:
Naja, bei OpenVPN hätte man recht simpel die Möglichkeit, die Verbindung per 443 TCP aufbauen zu lassen, das wird in Gastnetzen mit Internet immer frei sein.Was ist wahrscheinlicher, dass IPSec oder OpenVPN in Gast-Netzen, Hotspots usw freigegeben ist?
Vermutlich, denn es ist einfacher SSL basierte VPN Protokolle mit singulären Ports zu blocken. Sowas ist aber reine Kaffeesatzleserei.Zitat von @aqui:
Selbst wenn ich augenscheinlich alles richtig gemacht habe, kam die IPSec Verbindung trotzdem nicht zu stande ;) Ich sag nur Lancom.Meine Erfahrungen mit IPSec waren bisher: "entweder es geht oder es geht nicht".
Gilt ja letzlich für alle VPN Protokolle und Verfahren. Wenn man es falsch macht klappt es eben nicht. Einfache Logik! MfG
