Gelöst
DNS über VPN funktioniert nicht für lange domainnamen
vor 4 Jahren
Ich arbeite im Homeoffice, bis vor kurzem problemlos über 1und1 mit einer Fritzbox. Nun bin ich zur Telekom gewechselt mit einem Speedport Smart 4 Router. Seitdem funktioniert die Domain-Name-Auflösung für die Interne Infrastruktur nicht mehr zuverläßig. Für A-Records (DNS-Name -> IP) funktioniert zwar alles soweit ganz gut, für längere Records (domain-name -> cname-record -> cname-record -> IP) funktioniert es jedoch nicht mehr. Daher vermute ich ein MTU-Problem / Paket-Fragmentierungs-Defragmentierungs-Problem irgendwo auf dem Übertragungsweg.
Genutzte Produkte:
* VPN (Protokoll: Juniper)
* Speedport Smart 4
* Linux (Fedora) Desktop Betriebssystem
* openconnect VPN client software
Konfiguration:
* Wlan: mtu 1400
* VPN : mtu 1400 (hatte ich zum ausprobieren auch schon auf 1350 reduziert)
Das Problem behindert meine Arbeit relativ stark. Ich kann heute Abend ausprobieren, ob ich die alte Fritz-Box konfiguriert bekomme, und ob damit alles wie vorher funktioniert, um das Problem näher einzugrenzen.
1016
0
24
Das könnte Ihnen auch weiterhelfen
vor 2 Jahren
232
0
1
464
0
6
vor 4 Jahren
1322
0
2
1426
0
2
1208
0
2
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
Akzeptierte Lösung
akzeptiert von
vor 4 Jahren
Hallo @tho74
Haste noch die FritzBox?
Falls ja, anklemmen.
22
von
vor 4 Jahren
@tho74 wie groß ist denn das entscheidende Antwort-Paket, wenn es denn durch kommt?
0
von
vor 4 Jahren
Hier sind ein paar Header-Daten (leicht anonymisiert) Record A
Frame 3: 229 bytes on wire (1832 bits), 229 bytes captured (1832 bits) Raw packet data Internet Protocol Version 4, Src: 192.a.b.c, Dst: 10.x.y.z 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 229 Identification: 0xdc52 (56402) Flags: 0x00 ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 62 Protocol: UDP (17) Header Checksum: 0x291a [validation disabled] [Header checksum status: Unverified] Source Address: 192.a.b.c Destination Address: 10.x.y.z User Datagram Protocol, Src Port: 53, Dst Port: 59115 Source Port: 53 Destination Port: 59115 Length: 209 Checksum: 0x6aff [unverified] [Checksum Status: Unverified] [Stream index: 0] [Timestamps] UDP payload (201 bytes) Domain Name System (response)Record AAAA
Frame 4: 279 bytes on wire (2232 bits), 279 bytes captured (2232 bits) Raw packet data Internet Protocol Version 4, Src: 192.a.b.c, Dst: 10.x.y.z 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 279 Identification: 0xdc53 (56403) Flags: 0x00 ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 62 Protocol: UDP (17) Header Checksum: 0x28e7 [validation disabled] [Header checksum status: Unverified] Source Address: 192.a.b.c Destination Address: 10.x.y.z User Datagram Protocol, Src Port: 53, Dst Port: 33302 Source Port: 53 Destination Port: 33302 Length: 259 Checksum: 0x4c78 [unverified] [Checksum Status: Unverified] [Stream index: 1] [Timestamps] UDP payload (251 bytes) Domain Name System (response)0
von
vor 4 Jahren
@tho74
Spontan würde ich hier eher ein Problem mit den privaten Subnetzen sehen, normalerweise hat die FB ja eine 192.168.178.1 und der Speedport die 192.168.2.1. Hast Du daran was geändert? Falls nein, funktioniert es wenn Du den Speedport auf 192.168.178.1 setzt?
0
Uneingeloggter Nutzer
von
vor 4 Jahren
Wlan: mtu 1400
Die Default-MTU im lokalen Netz für IPv4 ist doch eigentlich 1500 🤔
0
0
Uneingeloggter Nutzer
von