VPN | GRE | Manche Pakete erreichen Gegenstelle nicht

[RcRaCk2k]

Hi!

Ich nutze ein VPN über einen GRE-Tunnel der Inhalt wird dabei nicht via IPSEC verschlüsselt - es ist ein nackter GRE-Tunnel (Generic Routing Encapsulation Protocol).

Das geniale ist, dass ich auf meinen OUT-Interface sehen kann, wie das GREv0 Paket meinen Router verlässt, somit auch zum Kabelmodem (CISCO) transferiert wird. Jedoch sehe ich an der Gegenstelle dieses GRE-Paket nicht.

Es handelt sich hierbei um ein ICMP-Paket, welches mit TTL 1 via "mtr" an die Gegenstelle gesendet wird.
Ein normaler PING mit TTL 64 wird ganz normal über den Tunnel beantwortet.

Es sieht also ganz danach aus, als ob Kabel-Deutschland GRE-Pakete untersucht!

Vielleicht kann jemand, mit dem entsprechenden Knowhow ebenso einen GRE-Tunnel zwischen zwei Endstellen aufbauen und mir sagen, ob er das gleiche Problem beobachten kann.

Über mein verschlüsseltes VPN z.B. funktioniert alles wunderprächtig.

[dMopp]

Selbes Problem mit OpenVPN.

[fLoo]

Habe es heute mal von der Arbeit nach Hause getestet (wir haben auf der Arbeit neben der Standleitung auch noch einen KDG-Business-Anschluss). Das gleiche Phänomen.

[dMopp]

das liegt an der grandios bescheidenen Verbindungsqualität ... Mit "TCP" statt UDP soll das Problem (logisch) verschwunden sein. Ist aber keine Lösung, da es nur die Auswirkung unterdrückt.

[RcRaCk2k]

Selbes Problem mit OpenVPN.

GRE tunnelt auf IP Ebene, ist also ein eigenes Protokoll wie UDP / TCP.

OpenVPN tunnelt auf IP/TCP und IP/UDP Ebene, je anch Konfiguration.

Bei meinem UDP-Tunnel via TUN/TAP habe ich ehrlich gesagt keine Probleme.

Bei GRE jedoch schon.

Selbst mein Routing-Protokoll, egal ob BATMAN oder OLSR oder OSPF schmeißt die Route über den GRE-Tunnel nach wenigen Sekunden raus.

Früher war es so, dass wenn zwischen 18 und 24 Uhr die GENERALDROSSEL aktiv war, du mit GRE noch voll 100 MBit bekommen hast. Anscheinend hatten das auch Andere heraus gefunden und seither ist auch GRE unter den Fittichen der QoS-Regelung in Abendszeiten. Und das sogar bei Business-Anschlüssen...

Echt ein Grauß. Man sollte prüfen, ob bei Business-Produkten erwartet werden kann, dass IP-Tunnel ohne Einschränkungen funktionieren.

VoIP ist über den GRE Tunnel so gut wie gar nicht möglich!

[manawyrm]

DAS ist mal interessant.

Ich hatte sehr ähnliche Probleme mit einmal einem GRE-Tunnel zu Hetzner und einmal einem IPv6-Protokoll 41-Tunnel zu he.net.
Meine Router ist hier eine Kabel–Fritte 6360 an einem Home-Anschluss.

Ich probier das Morgen nochmal an unserer Leitung in der Firma.

Ich vermute eig. immernoch ein Problem mit der Einstellung der MTU bei den Tunneln, konnte das aber so auch nicht bestätigen.

[RcRaCk2k]

TCP-Clamping (TCP MSS) musst du auf jeden Fall aktivieren, da sonst dein Router zu große Paket verwirft.

Unter Linux geht das so:

/sbin/iptables -t mangle -A PREROUTING -i gre+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1381:65535 -j TCPMSS --set-mss 1380
/sbin/iptables -t mangle -A POSTROUTING -o gre+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1381:65535 -j TCPMSS --set-mss 1380

Damit begrenzt du die TCP-Sessions auf eine MSS (Payload) von maximal 1380 + Ethernet (6 bytes) + IP-Header (20 bytes).

PS: Ich habe das Problem mit dem TTL gefunden. Man kann bei GRE den TTL auf inherit stellen. Wenn nun ein Datenpaket ankommt, mit TTL 1, dann sendet er das GRE-Paket ebenso mit TTL 1 weg, das wäre dann der Router hinter dem CMTS. Also geht das GRE-Paket nicht bis zur Endstelle vom Tunnel sondern endet im KD Netz. Ich habe nun die TTL auf 12 Hops fixiert, nun funktioniert der GRE-Tunnel wie erwartet.

Und ich muss sagen, dass ich mit meinem GRE-Tunnel eine bessere Performance habe, als wie mit meinem UDP-Tunnel.

Code: Alles auswählen

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 97.6M  100 97.6M    0     0  9364k      0  0:00:10  0:00:10 --:--:--  9.8M

9.8M mit Hintergrundtraffic. Insgessamt hat BWM-NG 11.2MB zu der Zeit gemessen. Also volle 100 MBit um 22:35 Uhr.