Mit Wireguard keine Verbindung zu "telekom.de"

[now2]

Ich habe ein seltsames Problem mit Wireguard. Wenn die VPN-Verbindung steht, funktionieren alle Dienste und URLs, bis auf "telekom.de".

Zum Setup:
Anschluss A
Telekom Glasfaser
Fritzbox 7590
192.168.2.0/24
Wireguard IP Netzwerk 100.64.64.0 /24 (Der 100.64.0.0 /10 Adress Block wird im Internet nicht geroutet (RFC 6598)).
Dedizierte Linux-Maschine mit Wireguard, Masquerading aktiviert

Wireguard-Config:

[Interface]
Address = 100.64.0.1/10
ListenPort = 54321
PrivateKey = <redacted>

[Peer]
PublicKey = <redacted>
AllowedIPs = 100.64.0.2/32

Anschluss B
Telekom Glasfaser
Unifi Dream Machine Pro
192.168.1.0/24
Wireguard IP Netzwerk 100.64.64.0 /24

Wireguard-Config:

[Interface]
PrivateKey = <redacted>
Address = 100.64.0.2/32
DNS = 192.168.2.1

[Peer]
PublicKey = <redacted>
AllowedIPs = 0.0.0.0/0
Endpoint = meindyndns:54321
PersistentKeepalive = 25

Problem:
Auf Seiten des Anschlusses B funktionieren bei bestehender VPN-Verbindung alle Internet-Dienste und alle Internet-Seiten. Lediglich ausschließlich die URL https://telekom.de wird nicht geladen.

Getestete Varianten:
Auf Seiten des Anschlusses B habe ich diverse Varianten durchgespielt:

1) Wireguard-Client unter Windows
Installation des WG-Client unter Windows 11 mit o.g. Config führt zum beschriebenen Problem

2) Wireguard auf der Dream Machine, über policy based routing dem Windows-Client zugewiesen: führt ebenfalls zum beschriebenen Problem

3) anderer DNS-Server in der Config (getestet mit 8.8.8.8 und 192.168.1.1) führen ebenfalls zum beschriebenen Problem

4) Andere Allowes-IP (getestet mit 100.64.0.1/32 sowie 100.64.0.0/24 führt ebenfalls zum beschriebenen Problem.

Ich bin wirklich überfragt, weil ja alle anderen Internetseiten durch den Tunnel gehen. Hat jemand eine Idee?

 

[Supaman]

Warum unbedingt eine 100er Tunneladresse? Bloss weil es nicht ins Internet geroutet wird, heisst das nicht, das die Router IPs für CGN intern brücksichtigen.

Ich würde die üblichen private IP Bereiche (10.x.x.x , 172.16.x , 192.168.x.x) für den Tuunel nehmen. Die einzige Bedingungist, das die Tunnel Netzwerk IPs nicht in den Quell- oder Ziel Netzzen verwendet werden.

 

[now2]

Warum unbedingt eine 100er Tunneladresse? Bloss weil es nicht ins Internet geroutet wird, heisst das nicht, das die Router IPs für CGN intern brücksichtigen.

Ich würde die üblichen private IP Bereiche (10.x.x.x , 172.16.x , 192.168.x.x) für den Tuunel nehmen. Die einzige Bedingungist, das die Tunnel Netzwerk IPs nicht in den Quell- oder Ziel Netzzen verwendet werden.

Weil dies als Best Practice in der c't und zB https://administrator.de/tutorial/merkzettel-vpn-installation-mit-wireguard-660620.html genannt wird.
Die 100.64.0.0/10 wird in den Routingtables weder an den Clients, noch am Router genannt (außer für die konfigutierte VPN-Verbindung), daran kann es also nicht liegen.

 

[BobbyD]

Frag doch bei der Telekom nach, warum die Seite nicht geht.

 

[Supaman]

Die 100.64.0.0/10 wird in den Routingtables weder an den Clients, noch am Router genannt (außer für die konfigutierte VPN-Verbindung), daran kann es also nicht liegen.

Das vermutest Du, aber Gewissheit hast Du erst, wenn Du es mit anderen IPs (10.x.x.x etc) ausprobiert hast.

Mag sein, das es unwahrscheinlich ist, aber es bleibt nicht viel übrig, was man noch ausprobieren kann.

 

[TheBigG]

Das vermutest Du, aber Gewissheit hast Du erst, wenn Du es mit anderen IPs (10.x.x.x etc) ausprobiert hast.

Das ist gewiss da viele Business VPN lösungen das 100.64.0.0/10 Netz nehmen, gäbe es da Adress Konflikte bei der Telekom wäre da gerade Alarm Stufe Rot das auf Seiten der Telekom zu fixen.
Zum topic, ich würde mit TCPdump gucken wo es hakt und dem Interface beim Anschluss A auch eine einzelne IP geben und nicht /10 geben.
Dann würde ich noch die Frage in den Raum stellen was dieses Setup überhaupt erreichen soll? Den kompletten Traffic über einen anderen Anschluss zu Tunneln ist alles andere als performant.

 

[now2]

Danke für Deine Antwort und das gute Auge - habe auf Site A nun auf /32 geändert (leider immer noch keinen Erfolg).
Ich habe jetzt 2 Wirehark Captures gemacht, einmal ohne VPN (telekom.de lädt) und einmal mit VPN (telekom.de lädt nicht) - leider bin ich nicht schlau genug, zu analysieren, wo nun der Fehler liegt. Schaue ich da nach fehlenden SYN-ACKs?

Klar, performant ist das nicht, aber an einem der beiden Anschlüsse habe ich Magenta-TV und würde über Policy Based Routing nur den Traffic des Fernsehers zur Telekom durch den VPN-Tunnel leiten. Durch den Tunnel gehen so 200 MBit in jede Richtung bei ca. 5 ms Latenz, das ist schon flott genug für TV.

 

[Zyxx]

Ich habe hier am PC Wireguard gegen meine Router und gegen meine VPS getestet und sowohl über IPv4 als auch v4/v6 im Tunnel genutzt um auf telekom.de zuzugreifen.
Dabei rausgefunden das telekom.de nur auf v4 auflöst, ansonsten lief alles einwandfrei.

Selbiges mit Android Tablet und Handy.

Ebenfalls Telekom Glasfaser hier.

Setz mal testweise:

MTU = 1412

in deiner Clientconfig, nicht das bei dir die Pakete segmentieren da zu groß bei Zugriff auf die Seite.
Damit würdest du das aushebeln und die Wireguard UDP Pakete ganz bleiben.

 

[TheBigG]

Danke für Deine Antwort und das gute Auge - habe auf Site A nun auf /32 geändert (leider immer noch keinen Erfolg).
Ich habe jetzt 2 Wirehark Captures gemacht, einmal ohne VPN (telekom.de lädt) und einmal mit VPN (telekom.de lädt nicht) - leider bin ich nicht schlau genug, zu analysieren, wo nun der Fehler liegt. Schaue ich da nach fehlenden SYN-ACKs?

Guck doch erstmal auf VPN Server A ob da überhaupt der Traffic für telekom.de durch kommt.

Klar, performant ist das nicht, aber an einem der beiden Anschlüsse habe ich Magenta-TV und würde über Policy Based Routing nur den Traffic des Fernsehers zur Telekom durch den VPN-Tunnel leiten. Durch den Tunnel gehen so 200 MBit in jede Richtung bei ca. 5 ms Latenz, das ist schon flott genug für TV.

Magenta-TV ist doch mittlerweile ein OTT dienst, ich verstehe ehrlichgesagt nicht was für einen Zweck das VPN überhaupt erfüllen soll oder willst du an beiden Standorten gleichzeitig Magenta-TV gucken?
Dann, da du Policy Based Routing machst dürften bis auf der TV nichts über das VPN geroutet werden, also hast du das Problem mit Clients die überhaupt nicht das VPN nutzen?

 

[now2]

Guck doch erstmal auf VPN Server A ob da überhaupt der Traffic für telekom.de durch kommt.

Klar, auf A kommt alles durch.

Magenta-TV ist doch mittlerweile ein OTT dienst, ich verstehe ehrlichgesagt nicht was für einen Zweck das VPN überhaupt erfüllen soll oder willst du an beiden Standorten gleichzeitig Magenta-TV gucken?
Dann, da du Policy Based Routing machst dürften bis auf der TV nichts über das VPN geroutet werden, also hast du das Problem mit Clients die überhaupt nicht das VPN nutzen?

Ich habe das Problem ja unabhängig von der Anwendung. Primär möchte ich mal verstehen, wieso alles problemlos durch den Tunnel läuft, die Website der Telekom dagegen nicht. Das muss ja irgend einen wilden Grund haben...

Die Anwendung ist wie gesagt sekundär, weil Du danach gefragt hast. Bei Magenta TV kann ich 5 Geräte anmelden, bzw die werden automatisch durch den Anschluss provisioniert. Ist Magenta zum Anschluss dazugebucht, wird die App automatisch entsprechend provisioniert.
Da das am TV nicht geklappt hat (ewige Verzögerung beim Laden mit einer entsprechenden Fehlermeldung nach einigen Minuten), habe ich meinen Rechner entsprechend mit in die Policy aufgenommen und damit die .pcapng Logs erzeugt.

 

[BobbyD]

Primär möchte ich mal verstehen, wieso alles problemlos durch den Tunnel läuft, die Website der Telekom dagegen nicht.

Bei mir ging sie gestern auch nicht, bin aber auch kein Kunde von denen und werde es auch nie mehr, aber gerade lädt die Site bei mir. So oder so, das Problem wird an der Site liegen, wenn alles andere geht.

 

[Seratio]

Mach doch erstmal einen Traceroute vom VPN Router zur Telekom und anschließend vom nicht funktionierenden Client zur Telekom. Und das Ergebnis schickst du uns dann. Am besten mit deaktivierter Namensauflösung.

Zudem wäre es gut zu wissen, was für eine Art von Anschluss deine Glasfaser Anschlüsse sind. Aka Dual Stack, oder DS-Lite. Bei letzterem insbesondere in Verbindung mit Wireguard, was vermutlich auf der UDM und der Fritze direkt läuft? könnte auch die Routing Tabelle des Routers in die Suppe spucken.

Beitrag automatisch zusammengeführt: 05.08.2024

Das ist gewiss da viele Business VPN lösungen das 100.64.0.0/10 Netz nehmen,

Ich habe schon viele Business VPNs gesehen und habe ein solches Konstrukt noch nie gesehen. Gut geplante Netze sind auf solch Frickeleien auch nicht wirklich angewiesen.

 

[TheBigG]

Ich habe schon viele Business VPNs gesehen und habe ein solches Konstrukt noch nie gesehen. Gut geplante Netze sind auf solch Frickeleien auch nicht wirklich angewiesen.

RFC 6598 ist dafür da damit man eben nicht auf Frickeleien angewiesen ist. Die vielen Business VPNs die du gesehen hast wurden wohl dann in den letzten 15 Jahren nicht auf aktuellen Stand gebracht. Da waren wahrscheinlich die gleichen "Experten" am Werk die auch bis heute noch nicht mitbekommen haben das es neue gTLDs gibt.

 

[Seratio]

Erklär mir mal bitte, wo in dem RFC steht, dass dieser auch für VPN Verbindungen gedacht ist.

Und ein Business VPN ist in dem sprech kein CGNAT.

 

[now2]

Erklär mir mal bitte, wo in dem RFC steht, dass dieser auch für VPN Verbindungen gedacht ist.

Und ein Business VPN ist in dem sprech kein CGNAT.

Da Du ihn ja offenbar auch gelesen hast, hast Du vermutlich Seite 4 überlesen, oder?

RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to...

datatracker.ietf.org

Shared Address Space is IPv4 address space designated for Service
Provider use with the purpose of facilitating CGN deployment. Also,
Shared Address Space can be used as additional non-globally routable
space on routing equipment that is able to do address translation
across router interfaces when the addresses are identical on two
different interfaces.

Wo genau steht da, dass man den Adressraum nicht für VPN-Verbindungen nutzen darf?

 

[BobbyD]

Mal eine Gegenfrage, was ist konkret damit gemeint:

on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

Zuvor wird nämlich gesagt, dass dies im Unterschied zu RFC1918 eine Limitierung sei. Und damit sehe ich im konkreten Beispiel jetzt auch keinen Anwendungsfall dafür. Nur weil es geht, muss man das nicht machen, insbesondere wenn es dafür gar nicht vorgesehen ist.

Und noch mal zur eigentlichen Frage. Wer weiß schon, was für eine WAF die Telekom einsetzt und wie die eingestellt ist oder war. Darüber zu spekulieren ist müßig.

 

[now2]

Mal eine Gegenfrage, was ist konkret damit gemeint:

Damit sind Geräte gemeint, die NAT-Loopback-fähig sind, also eigentlich alle Layer-3-Switches.

 

[BobbyD]

Eine so große Range (100.64.0.1/10) zu benutzen ist auf jeden Fall unklug. Was, wenn ein Teilnehmer selbst CG-NAT an seinem WAN hat. Auch nutzen andere Overlay-Netzwerke wie Tailscale diese Range. Letztlich spricht wohl sehr wenig für eine Nutzung dieser Range fürs eigene VPN.

 

[now2]

Die Verwendung der Range ist im Gegenteil klug, weil damit die Chance minimiert wird, in fremden WLANs wie Flughafen, Hotels, Restaurants, Cafes, bei Freunden, die im NAT eine 10/8, 172.16/12 oder 192.168/16 Range haben in Konflikte zu kommen. Aber da können wir gern in einem getrennten Beitrag weiter philisophieren, hier würde ich gern einfach nur das Problem lösen.

 

[BobbyD]

hier würde ich gern einfach nur das Problem lösen.

Hab es gerade noch mal getestet: Ich bin kein Telekomkunde und komme mit WG ebenfalls nicht auf die Site, ohne WG wird die Site geladen. Daraus schließe ich, dass die WAF einen VPN Zugriff verhindert, vielleicht anhand der MTU? Das wird dir nur die Telekom beantworten können.

Beitrag automatisch zusammengeführt: 11.08.2024

Wobei lag wohl am FF, da macht die Site keinen redirect. Wenn ich die Adresse nach dem Redirect nehme, funktioniert es bei mir überall.

https://www.telekom.de/

Muss man dafür wirklich einen eigenen Thread aufmachen?

 

[now2]

Hab es gerade noch mal getestet: Ich bin kein Telekomkunde und komme mit WG ebenfalls nicht auf die Site, ohne WG wird die Site geladen. Daraus schließe ich, dass die WAF einen VPN Zugriff verhindert, vielleicht anhand der MTU? Das wird dir nur die Telekom beantworten können.

Hm? telekom.de lädt generell nicht mit Wireguard bei Dir?
Bei @Zyxx lief es aber in #8? Sehr seltsam!

Muss man dafür wirklich einen eigenen Thread aufmachen?

Zwar nicht bei mir, aber bei anderen besteht hier offenbar Diskussionsbedarf, weil ¾ der Beiträge offtopic sind.

 

[Zyxx]

Grade auch nochmal getestet, die Seite läuft über Wireguard einwandfrei.

Nachtrag, wenn ich mein VPS im Ausland nutze und versuche auf Telekom.de zu verbinden lädt es grade nicht.

 

[Zyxx]

So, grade nochmal getestet.
Die Seite lässt sich über Wireguard wieder aufrufen.
Getestet über Mobilfunknetz zu mir nach Hause als WG Strecke, über Mobilfunknetz zu zweien meiner VPS und aus dem Firmen WLAN zu besagten Endpunkten.

Wobei der Seitenaufbau über meinen heimischen Router als WG Endpoint die Website ohne merkliche Verzögerung öffnete, von den andern Punkten dauerte es so 2-3 Sekunden.

Schon interessant, eventuell haben die Probleme mit dem Host der Seite?