8
Langsamer VPN-Zugriff nur bei einem virtuellen Server
Hallo!
Seit einigen Tagen habe ich ein seltsames Problem beim Zugriff auf einen virtuellen Server über einen SSL-Tunnel mit OpenVPN. Zunächst möchte ich meine Umgebung kurz beschreiben:
Auf diesem Host laufen unter anderem drei virtuelle Server:
Das Netzwerk ist über eine UTM-Firewall von Securepoint mit dem Internet verbunden. Diese stellt über einen SSL-Tunnel auf Basis von OpenVPN eine Verbindung zu einem weiteren Standort (S2S-Verbindung) her. Darüber hinaus dient sie als Zugangspunkt für Remote-Arbeitsplätze (Roadwarriors) – ebenfalls unter Verwendung von OpenVPN.
Das beschriebene Problem tritt sowohl bei der S2S- als auch bei der Roadwarrior-Verbindung auf.
Seit einigen Tagen ist der Zugriff auf den Dateiserver über das SSL-VPN extrem langsam, während alle anderen Server (virtuell oder physisch) normal arbeiten. Der Zugriff auf den Dateiserver über das LAN ist dagegen normal schnell. Das verwirrt mich.
Der Zugriff auf den Domänencontroller ist unabhängig davon, ob über LAN oder VPN, normal schnell. Das Gleiche gilt für den Datenbankserver. Zur Überprüfung habe ich die Verbindung zu einem UBUNTU-Server im Netzwerk ohne Performanceverluste getestet. Das Problem tritt also nur beim Dateiserver auf, und zwar nur, wenn über VPN darauf zugegriffen wird, unabhängig davon, ob es sich um die S2S- oder die Roadwarrior-Verbindung handelt.
Hat jemand schon einmal ein ähnliches Problem erlebt und kennt möglicherweise dessen Lösung?
Danke und liebe Grüße,
René
Seit einigen Tagen habe ich ein seltsames Problem beim Zugriff auf einen virtuellen Server über einen SSL-Tunnel mit OpenVPN. Zunächst möchte ich meine Umgebung kurz beschreiben:
Gerätename BLECH1
Prozessor Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz 3.70 GHz
Installierter RAM 64,0 GB (63,9 GB verwendbar)
Systemtyp 64-Bit-Betriebssystem, x64-basierter Prozessor
Betriebssystem Windows Server 2022 Datacenter 21H2Auf diesem Host laufen unter anderem drei virtuelle Server:
- Domänencontroller
- Datenbankserver
- Dateiserver
Das Netzwerk ist über eine UTM-Firewall von Securepoint mit dem Internet verbunden. Diese stellt über einen SSL-Tunnel auf Basis von OpenVPN eine Verbindung zu einem weiteren Standort (S2S-Verbindung) her. Darüber hinaus dient sie als Zugangspunkt für Remote-Arbeitsplätze (Roadwarriors) – ebenfalls unter Verwendung von OpenVPN.
Das beschriebene Problem tritt sowohl bei der S2S- als auch bei der Roadwarrior-Verbindung auf.
Seit einigen Tagen ist der Zugriff auf den Dateiserver über das SSL-VPN extrem langsam, während alle anderen Server (virtuell oder physisch) normal arbeiten. Der Zugriff auf den Dateiserver über das LAN ist dagegen normal schnell. Das verwirrt mich.
Der Zugriff auf den Domänencontroller ist unabhängig davon, ob über LAN oder VPN, normal schnell. Das Gleiche gilt für den Datenbankserver. Zur Überprüfung habe ich die Verbindung zu einem UBUNTU-Server im Netzwerk ohne Performanceverluste getestet. Das Problem tritt also nur beim Dateiserver auf, und zwar nur, wenn über VPN darauf zugegriffen wird, unabhängig davon, ob es sich um die S2S- oder die Roadwarrior-Verbindung handelt.
Hat jemand schon einmal ein ähnliches Problem erlebt und kennt möglicherweise dessen Lösung?
Danke und liebe Grüße,
René
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 83934182426
Url: https://administrator.de/contentid/83934182426
Printed on: April 30, 2024 at 08:04 o'clock
8 Comments
Latest comment
Moin.
Hört sich für mich nach MTU Problematik an. Prüfe als erstes ob der Dateiserver von den Clients aus per ICMP erreichbar ist und alle Firewalls durchgehend keine ICMP-Pakete blockieren vor allem der ICMP Type 3 (auch am Dateiserver), damit die Path MTU (PMTU) Ermittlung der Clients vernünftig funktioniert. Prüfe dann auch mal mit Ping die MTU mit gesetztem do not fragment bit indem du dich schrittweise nach unten tastest bis die Pakete durchgehen
Dann mal einen Wireshark Mitschnitt am Server und am Client machen und schauen ob hier vermehrt retransmissions und Fragmentierung mit den Clients auftreten.
Welche Settings hat die UTM bezüglich MTU im VPN?
Ist in dem virtuellen Server zufällig Hardware Offloading auf der NIC aktiviert? Wenn ja dies mal deaktivieren.
Welcher Hypervisor?
Gruß
Hört sich für mich nach MTU Problematik an. Prüfe als erstes ob der Dateiserver von den Clients aus per ICMP erreichbar ist und alle Firewalls durchgehend keine ICMP-Pakete blockieren vor allem der ICMP Type 3 (auch am Dateiserver), damit die Path MTU (PMTU) Ermittlung der Clients vernünftig funktioniert. Prüfe dann auch mal mit Ping die MTU mit gesetztem do not fragment bit indem du dich schrittweise nach unten tastest bis die Pakete durchgehen
ping -f -l 1450 <zielserver>Welche Settings hat die UTM bezüglich MTU im VPN?
Ist in dem virtuellen Server zufällig Hardware Offloading auf der NIC aktiviert? Wenn ja dies mal deaktivieren.
Welcher Hypervisor?
Gruß
2
Die MTU ist überall durchgängig auf 1500 gesetzt. Ein Ping vom Roadwarrior zum Dateiserver über die VPN-Verbindung ist bis zur Paketgröße von 1472 Byte erfolgreich.
Das Hardware-Offloading (Large Send Offload Version 2) ist auf der virtuellen Netzwerkkarte aktiviert. Ich habe es testhalber deaktiviert und führe weitere Tests durch.
Als Hypervisor nutze ich Hyper-V von Microsoft.
C:\Users\rkk>ping -f -l 1472 192.168.70.200
Ping wird ausgeführt für 192.168.70.200 mit 1472 Bytes Daten:
Antwort von 192.168.70.200: Bytes=1472 Zeit=45ms TTL=127
Antwort von 192.168.70.200: Bytes=1472 Zeit=44ms TTL=127
Antwort von 192.168.70.200: Bytes=1472 Zeit=44ms TTL=127
Antwort von 192.168.70.200: Bytes=1472 Zeit=50ms TTL=127
Ping-Statistik für 192.168.70.200:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 44ms, Maximum = 50ms, Mittelwert = 45msDas Hardware-Offloading (Large Send Offload Version 2) ist auf der virtuellen Netzwerkkarte aktiviert. Ich habe es testhalber deaktiviert und führe weitere Tests durch.
Als Hypervisor nutze ich Hyper-V von Microsoft.
Die MTU ist überall durchgängig auf 1500 gesetzt.
Was für einen VPN Tunnel ja falsch ist. Ganz besonders wenn auch noch PPPoE als externer Overhead dazukommt. https://baturin.org/tools/encapcalc/Wichtig wäre noch zu wissen ob du mit UDP oder mit TCP Encapsulation im OVPN Tunnel arbeitest?! 🤔
ist bis zur Paketgröße von 1472 Byte erfolgreich.
Was dein falsches Tunnel MTU Setup dann bestätigt!https://www.thegeekpub.com/271035/openvpn-mtu-finding-the-correct-settin ...
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ..).
1Zitat von @aqui:
Die MTU ist überall durchgängig auf 1500 gesetzt.
Was für einen VPN Tunnel ja falsch ist. Ganz besonders wenn auch noch PPPoE als externer Overhead dazukommt. https://baturin.org/tools/encapcalc/OK, ich sehe hier einiges an Optimierungspotential – gebe ich dir recht. Dennoch erklärt das nicht, dass der Zugriff auf andere Ziele im Netzwerk über VPN schnell bleibt, während dieser auf den Dateiserver in den Keller geht. All das erst seit wenigen Tagen, ohne dass jemand etwas (außer Windows-Updates) geändert hätte.
Wichtig wäre noch zu wissen ob du mit UDP oder mit TCP Encapsulation im OVPN Tunnel arbeitest?! 🤔
UDP
ist bis zur Paketgröße von 1472 Byte erfolgreich.
Was dein falsches Tunnel MTU Setup dann bestätigt!https://www.thegeekpub.com/271035/openvpn-mtu-finding-the-correct-settin ...
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ..).
Interessant, danke! Ich werde die Einstellungen entsprechend anpassen und dann wieder testen. Die Frage bleibt aber: Warum erst jetzt und nur beim Dateiserver?
Das Hardware-Offloading (Large Send Offload Version 2) ist auf der virtuellen Netzwerkkarte aktiviert. Ich habe es testhalber deaktiviert und führe weitere Tests durch.
Es läuft etwas schneller, aber immer noch nicht wie es früher war
Wie gesagt, ein Wireshark Trace zeigt es dir sofort und du musst nicht x mal in der Gegend rum raten ....
Zus. sollte man auch die Best Practices für SMB Dateiserver über Remote Links beherzigen, SMB ist ja bekanntlich nicht gerade bekannt dafür sich mit Ruhm zu bekleckern was das betrifft ...
https://learn.microsoft.com/de-de/windows-server/administration/performa ...
Zus. sollte man auch die Best Practices für SMB Dateiserver über Remote Links beherzigen, SMB ist ja bekanntlich nicht gerade bekannt dafür sich mit Ruhm zu bekleckern was das betrifft ...
https://learn.microsoft.com/de-de/windows-server/administration/performa ...
1Zitat von @12168552861:
Wie gesagt, ein Wireshark Trace zeigt es dir sofort und du musst nicht x mal in der Gegend rum raten ....
Wie gesagt, ein Wireshark Trace zeigt es dir sofort und du musst nicht x mal in der Gegend rum raten ....
Werde ich als nächstes machen. Dann kann ich auch gleich die Unterschiede beim Hardware-Offloading sehen.
Zus. sollte man auch die Best Practices für SMB Dateiserver über Remote Links beherzigen, SMB ist ja bekanntlich nicht gerade bekannt dafür sich mit Ruhm zu bekleckern was das betrifft ...
https://learn.microsoft.com/de-de/windows-server/administration/performa ...
https://learn.microsoft.com/de-de/windows-server/administration/performa ...
Nochmals danke, ich werde das beherzigen.
Die antiken Durchsatzraten des etwas in die Jahre gekommenen OVPN machen das Ganze dann nicht unbedingt besser. Da gibt es bekanntlich bessere Alternativen ohne MTU Gefrickel.
Wenn es das denn war bitte deinen Thread dann als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?
