22.05.2023

3823

VPN Client Probleme seit Wechsel zu Telekom Hybrid

Hallo zusammen,
leider habe ich aktuell ein Verbindungsproblem mit einem Client der sich mittelts VPN an einem Synology Domain Controller anmelden will.

Zur aktuellen Konfiguration:

Server = Synology DS1019+ mit Synology Directory Server als Domain Controller - Die Synology läuft als DHCP/DNS/VPN Server
Router am Serverstandort = Fritzbox 5590
Router am Clientstandort = Telekom Speedport Pro Plus Hybrid DSL + LTE - dahinter Fritzbox 7590 als kaskadierter Router
VPN Software Server = Synology OpenVPN
VPN Software Client = OpenVPN 2.6.2 "Windows 10 64bit"
VPN Config Client =

dev tun
tls-client
remote ### ###
dhcp-option DNS 192.168.3.2
dhcp-option DNS IPv6 Adresse Synology Domain Server --> hab ich seit dem Problem hinzugefügt da es ein DNS Problem gibt
dhcp-option DOMAIN ###.local
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
###
-----END CERTIFICATE-----
</ca>

Problem:
Die oben aufgeführte Konfiguration läuft seit langem stabil mit mehreren Benutzern am Standort und auch außerhalb mit VPN. Nun wurde bei einem Client das Internet auf Telekom Hybrid umgestellt. Seit der Umstellung gibt es leider häufig Probleme mit dem Domain Server Zugriff. Hierbei wird die VPN Verbindung aufgebaut, doch es kommt häufig zu folgenden Problemen. Internet + Zugriffe sehr langsam / kein Zugriff auf Netzlaufwerke / Namensauflösung funktioniert nicht.
Ich habe bereits eine zusätzliche Verbindung via Wireguard vom Client zur ServerFritzbox konfiguriert und habe mit dieser Variante exakt die gleichen Probleme wie mit der OpenVPN Variante.

Ich hoffe mit den Infos kann mir jemand helfen?
Vielen Dank im Voraus und beste Grüße
Foradh

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7261304239

Url: https://administrator.de/contentid/7261304239

Ausgedruckt am: 22.11.2024 um 06:11 Uhr

19 Kommentare

Neuester Kommentar

Hi.

häufig können die Hybriden wegen nicht vorhandener public ip probleme bereiten. Ob das bei deinem Problem hilft, kann ich nicht sagen. Ein Versuch macht aber kluch.

Ändere mal den APN und lasse den Router neueinwählen, anschließend nochmals probieren.

Telekom APN (mit diesem Einwahlknoten solltest eine dynamische pub ip bekommen)

Gruß

Hi Emm386,
vielen Dank für die rasante Antwort. Soll ich hierbei die Einstellungen von " internet.v6.telekom" nehmen?
Was ich noch vergessen habe zu erwähnen, ist dass die Verbindung nach 2-3 mal trennen und wiederaufbauen dann plötzlich stabil funktioniert.

Soll ich hierbei die Einstellungen von

Ich würde die v4 Konfig nehmen (internet.telekom).

dann plötzlich stabil funktioniert.

Aha. Vielleicht musst Du mehr Kaffee in die Leitung kippen, dass die schneller aufwacht?

Tipp: sichere Dir die aktuelle Konfig für einen Rollback.

Grüße

Hallo,

ich hatte in der Vergangenheit ähnliche Probleme mit einem DSLite Anschluss bei Vodafone. Bitte prüfe mal die MTU-Größe und passe den Wert in der Clientconfig an.

Zitat von @techSmile:
ich hatte in der Vergangenheit ähnliche Probleme mit einem DSLite Anschluss bei Vodafone. Bitte prüfe mal die MTU-Größe und passe den Wert in der Clientconfig an.

Oh bei Voodoofone haben wir damit auch Probleme. Hast du das in den Griff bekommen und wenn ja, wie? Nur die MTU anpassen?

Zitat von @6376382705:

Soll ich hierbei die Einstellungen von

Ich würde die v4 Konfig nehmen (internet.telekom).

dann plötzlich stabil funktioniert.

Aha. Vielleicht musst Du mehr Kaffee in die Leitung kippen, dass die schneller aufwacht?

Tipp: sichere Dir die aktuelle Konfig für einen Rollback.

Grüße

Leider gibt es im dem Speedport Pro keinerlei Einstellmöglichkeiten für die APN

Zitat von @techSmile:

Hallo,

ich hatte in der Vergangenheit ähnliche Probleme mit einem DSLite Anschluss bei Vodafone. Bitte prüfe mal die MTU-Größe und passe den Wert in der Clientconfig an.

Beim Versuch die MTU Größe zu ermitteln ist mir folgendes aufgefallen. Sobald ich Werte über 1412 angebe bricht der Ping mit "zeitüberschreitung" ab.

C:\WINDOWS\System32>ping www.yahoo.com -f -l 1412

Ping wird ausgeführt für new-fp-shed.wg1.b.yahoo.com [87.248.100.215] mit 1412 Bytes Daten:
Antwort von 87.248.100.215: Bytes=1412 Zeit=69ms TTL=51
Antwort von 87.248.100.215: Bytes=1412 Zeit=69ms TTL=51
Antwort von 87.248.100.215: Bytes=1412 Zeit=65ms TTL=52
Antwort von 87.248.100.215: Bytes=1412 Zeit=66ms TTL=52

Ping-Statistik für 87.248.100.215:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 65ms, Maximum = 69ms, Mittelwert = 67ms

C:\WINDOWS\System32>ping www.yahoo.com -f -l 1413

Ping wird ausgeführt für new-fp-shed.wg1.b.yahoo.com [87.248.100.215] mit 1413 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Daher habe ich versucht die OpenVPN config mit "tun-mtu 1412" zu ändern. Leider erhalte ich aber im Client OpenVPN Log folgende Einträge.

Mon May 22 15:09:52 2023 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1514', remote='link-mtu 1602'  
Mon May 22 15:09:52 2023 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1412', remote='tun-mtu 1500'  

Kannst du mir ein Beispiel geben wie ich das richtig konfigurieren muss?

Vielen Dank

Zitat von @Foradh:
Daher habe ich versucht die OpenVPN config mit "tun-mtu 1412" zu ändern. Leider erhalte ich aber im Client OpenVPN Log folgende Einträge.

Mon May 22 15:09:52 2023 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1514', remote='link-mtu 1602'  
Mon May 22 15:09:52 2023 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1412', remote='tun-mtu 1500'  

Kannst du mir ein Beispiel geben wie ich das richtig konfigurieren muss?

Vielen Dank

Die Config-Einträge tun-mtu und mssfix müssen gesetzt werden.
Da der Server eine andere MTU-Größe vorgibt, kommt es zu den Fehlermeldungen - das kannst du aber ignorieren.

Die MTU-Größe müsste im Telekom Mobilfunknetz zwischen 1480 und 1490 liegen.
Versuche deshalb folgende Einträge:

tun-mtu 1480
mssfix 1440

mssfix ist immer MTU-Größe - 40

Vielen Dank für die Rückmeldung. Ich habe jetzt die MTU-Größe folgendermaßen definiert.

tun-mtu 1412
mssfix 1372

Alles was über den 1412 liegt wird entweder mit "Zeitüberschreitung der Anforderung" oder "Paket muss fragmentiert werden, DF-Flag ist jedoch gestetzt."

Was ich nicht so ganz verstehe ist, dass wenn ich nach hergestellter Verbindung die Domain anpinge, kommt auch bei der Größe von 1412 die Meldung "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt."
Ist das normal?

Z:\>ping domain.local -f -l 1412

Ping wird ausgeführt für domain.local [192.168.3.2] mit 1412 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 192.168.3.2:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),


Z:\>ping www.google.com -f -l 1412

Ping wird ausgeführt für www.google.com [142.250.184.228] mit 1412 Bytes Daten:
Antwort von 142.250.184.228: Bytes=68 (gesendet 1412) Zeit=38ms TTL=116

Ping-Statistik für 142.250.184.228:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 36ms, Maximum = 38ms, Mittelwert = 37ms


Z:\>ping www.google.com -f -l 1413

Ping wird ausgeführt für www.google.com [142.250.184.228] mit 1413 Bytes Daten:
Zeitüberschreitung der Anforderung.

Ping-Statistik für 142.250.184.228:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Nein und der Ping geht auch nicht durch.

Bitte mal weiter reduzieren. Als Bsp. tun-mtu 1380 und mssfix 1340
Ergänzend habe ich noch das Attribut fragment gefunden, welches den gleichen Wert wie mssfix beinhalten soll.

Einfach mal testen bis es klappt.

Alles klar, ab dem MTU 1359 geht der Ping durch ohne zu fragmentieren.
Also habe ich die config folgendes reingepackt

tun-mtu 1359
mssfix 1319
fragment 1319

Damit soll es nun mal getestet werden...
Nochmal vielen Dank....ich gebe wieder Rückmeldung ob es damit nun endlich wieder störungsfrei funktioniert.

Nachdem es nun gestern den ganzen Tag stabil gelaufen ist...heute früh leider wieder die Ernüchterung, Domain wird nicht gefunden und kann auch nicht angepingt werden trotz bestehender VPN Verbindung. Nach 2mal trennen und neu verbinden von OpenVPN funktioniert die Verbindung auf einmal wieder.
Mir ist aufgefallen dass im OpenVPN log mit der Option "fragment 1319" immer wieder folgender Fehler auftritt

FRAG_IN error flags=0xfa2a187b

Kann ich noch etwas anderes testen um den Fehler eingrenzen zu können?

Hallo, du könntest ggf. mal das Attribut Fragment weglassen und dann nochmal versuchen.

Wie bereits gesagt kann ich dir gar nicht genau sagen, was das bewirkt.

So, nachdem ich Fragment weggelassen habe, läuft die Verbindung nun störungsfrei.
Vielen Dank nochmal für die großartige Hilfe!

Beste Grüße
Foradh

Viel sinnvoller wäre es doch statt OpenVPN und seiner schlechten Skalierbarkeit die beiden FritzBoxen per VPN zu koppeln. Die können von sich aus VPN und man erspart sich die Frickelei mit einem eigentlich völlig überflüssigem separaten VPN.
Zudem erspart man sich auch den gravierenden Nachteil auf der Serverseite mit einem Loch in der Router Firewall ungeschützen Internet Traffic in das lokale LAN forwarden zu müssen. Und das dann gerade auch noch auf ein NAS was eigentlich prinzipbedingt besonders schützenswert ist.
VPN gehört bekanntlich immer auf die Peripherie besonders wenn man auch schon VPN fähige Router oder Firewall Hardware im Netz hat. Gutes VPN Design sieht anders aus...aber egal.

@aqui
Da es sich bei dem Client um ein Notebook handelt welches häufig auch mobil verwendet wird, ist die direkte VPN Kopplung der Fritzboxen leider nicht zweckmäßig.

Klappt ja auch immer direkt mit dem Notebook...

https://avm.de/service/vpn/ipsec-vpn-zur-fritzbox-unter-windows-einricht ...
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-6850-LTE/2275_VPN- ...

Die Lösung hatte ich tatsächlich früher mal am laufen. Allerdings vor der Zeit als AVM die VPN Software in Hardware berechnen lies...hier war die Verbindung wirklich sehr zäh. Klar mittlerweile läuft das deutlich besser und man kann auch direkt auf WireGuard gehen. Doch ich bin mit der OpenVPN Lösung wirklich sehr zufrieden.