Frage
Antwort
Lösung
am 28.03.2020 18:29
Betrifft Anschluss: xxxxxxxxxxx
Kundennummer: xxxxxxxxxxxxx
Tarif: Red Internet & Phone 100 Cable
Situation und Vorgeschichte
Nach Bestellung hatte ich einen Anschluss mit DSlite. (IPv6 Nativ, IPv4 nur über einen Tunnel).
In diesem Setup war die VPN Verbindung in meine Firma schlecht. Hoher Jitter und instabile Datenrate, nutzbare IPv4 MTU war nur 1460.
So hat man mir natives IPv4 „hinzugeschaltet“. Eigentlich war die Aussage, dass dies damit eine echtes „Dual Stack“ werden sollte (nativ IPv4 und auch weiterhin nativ IPv6). Leider ist es das nicht der Fall, ich habe jetzt nur noch IPv4. Echtes Dual Stack wäre sehr hilfreich für die Arbeit, ist aber nicht mein Hauptproblem.
Router/Gateway ist der von Vodafone gestellte (TG3442DE), Clients sind über WLAN mit dem Router verbunden.
Das eigentliche Problem
VPN Verbindung in die Firma kann aktuell nicht aufgebaut werden (PPTP basiertes VPN mit GRE als Transportprotokoll).
Grund
Mit Wireshark sieht man, dass die PPTP Aushandlung der Tunnelparameter noch funktioniert, aber alle nachfolgenden GRE Pakete verworfen werden (bzw. eine Antwort nie empfangen wird).
Cross-check
Gleicher Rechner, gleiches VPN, vor der Umschaltung auf IPv4 hat zumindest der Aufbau des Tunnels funktioniert (aber Performance war grottig, deswegen ist das keine Lösung!)
Gleicher Rechner, gleiches VPN über alternativen Internetzugang (DSL der Telekom) funktioniert aktuell fehlerfrei.
Anderer Rechner, gleiches VPN über gleichen Vodafone Kabel Internetzugang geht aktuell auch nicht.
Bisherige Maßnahmen
Abschalten vom Homespot Service wurde durchgeführt da dieser vermeintlich das Problem sei?
Hat aber keine Änderung gebracht.
Firewall auf dem Gateway versuchsweise abgeschaltet, ebenfalls ohne Erfolg.
Schlussfolgerung
Entweder mein lokaler Vodafone Router / Gateway oder irgendeine Instanz im Vodafone Netz scheint GRE nicht direkt durch zu lassen. Ggf. funktioniert das lokale NAT traversal für GRE (PPP LCP) auf dem Gateway nicht? (Achtung, Orakel-modus).
Mehr Screenshots, packet dumps etc. kann ich bei Bedarf gerne schicken
Gelöst! Gehe zu Lösung.
am 14.04.2020 20:43
Hi poeggi,
wie sieht´s eigentlich mit den Portfreigaben aus?
VG Wallace
am 15.04.2020 00:07
Moin @Wallace
ich denke nicht, dass man da was Port-forwarded kann. GRE ist ein eigenständiges IP basiertes Protokoll wie TCP oder UDP auch.
GRE kann man nicht über Ports "freischalten".
Der Mechanismus den der (NATende) Router können muss (und z.B. Mein Telekom Router auch kann!) ist NAT traversal.
Wenn der funktioniert dann automatisch und dynamisch, für beliebige Clients im LAN.
Oder aber ich habe Deine Frage nicht verstanden?
am 20.04.2020 11:36
Hallo poeggi,
wir haben den Fehler bei einem unserer anderen Router. Bei Deinem sollte es aber funktionieren.
Wallace meinte, ob Du irgendwelche bestimmten Ports freigegeben hast oder nicht.
Viele Grüße, Manu
am 20.04.2020 20:47
Danke. Also bei mir gibt es erwiesenermaßen das Problem mit GRE (PPP LCP), siehe dazu auch den Thread.
Ebenso erwiesen scheint mir, dass es wohl an der Router-config/firmware liegt.
Zur Frage von Wallace, nein, ich habe keine Portforwards. Meine ganze Config ist mehr oder weniger "Vanilla". Einzig den RFC1918 IP Adressbereich intern habe ich umgestellt auf 192.168.22.0/24
Und auch auf dem default Subnetz geht es nicht, gerade ausprobiert.
Gruß
am 24.04.2020 14:04
Hallo poeggi,
schick mir bitte eine PN mit deiner Rufnummer, dann leite ich dies mal an die Kollegen weiter.
Viele Grüße, Martin
am 24.04.2020 16:28
am 27.04.2020 16:52
Hi poeggi,
ich habe ein Ticket zur Prüfung an unsere Fachabteilung weiter gegeben.
Viele Grüße
Marco
am 28.04.2020 15:18
Habe heute mit den Kollegen der Fachabteilung gesprochen.
Es wurde ein update auf die Neue Firmware (AR01.02.051.08_030620_711.PC20.10) durchgeführt.
Diese behebt das Problem! Ich gehe jetzt in den Dauertest.
am 29.04.2020 16:02
Hi poeggi,
gib mir nach Deinem Test bitte noch eine Rückmeldung, ob ich den Thread schließen kann.
Viele Grüße
Marco
am 29.04.2020 16:12
Alle grundlegenden Tests was Verbindungsaufbau, Stabilität und Performance des Tunnels angeht sind abgeschlossen. Ich konnte keine Probleme mehr feststellen.
Das der hier initial beschriebene Fehler ja auch war, dass gar kein Tunnelaufbau möglich war, kann der Thread geschlossen werden.