L2TP-VPN wird manchmal nicht aufgebaut

[Christian S]

Hallo liebe Netzgemeinde,

wir haben für unser Büro den bestehenden DSL 16.000 Zugang über die Telekom wegen des Uploads um einen KD-Comfort 32.000 Zugang ergänzt. WIr nutzen einen Linksys RV042 Dual WAN Router (aktuelle Firmware) mit Load-Balancing. Soweit geht eigentlich alles ohne Probleme, bis auf einen L2TP-VPN (Windows-Bordmittel) zwischen verschiednene XP-Rechnern zu einem Kunden.

Der VPN wird mal aufgebaut, mal nicht. Es kommt dann einfach zu einem Timeout. Wenn dann die WAN-Verbindung zu KD per Release beendet wird und dadurch die Verbindung über die Telekom läuft, klappt alles wieder perfekt. Im Moment klappt der Aufbau über KD einwandfrei, ich kann auch keine bestimmten Uhrzeiten für die Verbindungs-Probleme finden.

Ich habe dann mal per Syslog alles Aktivitäten des Routers beobachtet, hier steht dann bei einem erfolgreichen VPN-Aufbau zuerst der Kontakt per UDP :500 und dann per UDP :4500 drin. Wenn der Aufbau nicht klappt, kommt es garnicht soweit. Also tippe ich auf ein Routing-Problem oder eine Port-Sperre.

Hat jemand eine Idee?

Christian

[RcRaCk2k]

Syslog -> also gehe ich davon aus, ihr betreibt Linux?

Das Routing hast du ja, denke ich jetzt mal, richtig eingestellt... Also zwei Default-Gateways... Nicht dass es zu dem Problem kommt, dass ein Paket über Leitung-A rein und über Leitung-B raus geht... Das würde extreme Probleme machen. Poste mal deine Einträge von ip rule show und ip route show.

Ich würde dir sowieso empfehlen, auf OpenVPN zu setzen, anstatt ein PPP über ein L2TP zu fahren. Schön ist natürlich, dass du keine Broadcast-Domäne hast, aber ich denke, dass das bei dir nicht so wichtig ist?

Wichtig ist auf jeden Fall das richtige Routing.
Was setzt ihr denn für eine Linux-Distribution ein?

[Christian S]

Wir setzen alle möglichen Betriebsysteme ein, aber das Routing geht zentral über den Linksys (Cisco) RV042 mit 2 WAN-Ports. Der macht dann das Loadbalancing, aber es lassen sich auch Ports / Protokolle und IP-Bereiche an bestimmte WAN-Ports binden. Die Kiste weist allen Arbeitsmaschinen im Haus per DHCP sich selbst als Gateway zu, der PC merkt also in der Regel nix von den 2 Leitungen ins Internet. Das sieht man erst bei einem Tracêroute (oder wenn man die aktuellen Verbindungen per Syslog ausgeben lässt)...

Und hier ist wohl der Hund begraben:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Dokumente und Einstellungen\Christian>tracert 93.190.250.138

Routenverfolgung zu vpn.XXXXX.de [XXX.XXX.XXX.XXX] über maximal 30 Abschnit
te:

1 1 ms 1 ms 1 ms 10.50.0.1
2 13 ms 16 ms 5 ms 83-169-167-14-isp.superkabel.de [83.169.167.14]

3 9 ms 18 ms 8 ms 83-169-178-150-isp.superkabel.de [83.169.178.150
]
4 7 ms 17 ms 9 ms 83-169-129-1-isp.superkabel.de [83.169.129.1]
5 20 ms 26 ms 8 ms 83-169-128-106-isp.superkabel.de [83.169.128.106
]
6 27 ms 9 ms 11 ms 83-169-128-89-isp.superkabel.de [83.169.128.89]

7 27 ms 27 ms 10 ms 0-1-0-1.ix-cr1.ffm.manet.de [80.81.192.3]
8 30 ms 12 ms 11 ms 212.65.9.29
14 ^C

oder

1 12 ms 2 ms 2 ms 10.50.0.1
2 7 ms 18 ms 7 ms 83-169-167-14-isp.superkabel.de [83.169.167.14]

3 1161 ms 7 ms 20 ms 217.237.152.174
4 7 ms 17 ms 11 ms 83-169-129-1-isp.superkabel.de [83.169.129.1]
5 9 ms 26 ms 10 ms 83-169-128-106-isp.superkabel.de [83.169.128.106
]
6 15 ms 11 ms 27 ms ae-3-89.edge3.Frankfurt1.Level3.net [4.68.23.139
]
7 55 ms 11 ms 24 ms 0-1-0-1.ix-cr1.ffm.manet.de [80.81.192.3]
8 32 ms 32 ms 110 ms 212.65.9.29

Die Route geht manchmal über Level3 und manchmal über ganz andere (UM)wege....

Ich werde mal alle Syslog-Optionen aktivieren und dann mal auf den Moment warten, wo es mal wieder hängt.

Christian

[Christian S]

Nachtrag:

Jetzt geht der VPN mal wieder nicht, im Router wird die ausgehende Verbindung noch angezeigt:

07-29-2010 19:48:09 Daemon.Info 10.50.0.1 Jul 29 19:48:09 2010 gateway RGFW-OUT: ACCEPT (UDP 10.50.0.150:4500->XXX.XXX.XXX.XXX:4500 on ixp2) [0,0]
07-29-2010 19:48:09 Daemon.Info 10.50.0.1 Jul 29 19:48:09 2010 gateway RGFW-OUT: ACCEPT (UDP 10.50.0.150:500->XXX.XXX.XXX.XXX:500 on ppp0) [0,0]

Und hier ist der Bug: UDP: 500 geht an ppp0 raus (DTAG), UDP:4500 an ixp2 (KD) !!!! Sauberes Load-Balancing...

[RcRaCk2k]

In deinem Traceroute habe ich schon gesehen, dass hier großer Mist passiert.

Dadurch, dass du das Routing in die Hand von CISCO legst, hast du natürlich nicht viel Handlungsspielraum, außer den, den dir CISCO gewährt. Hoffe du hast soviel Ahnung von dem Zeug, dass du das sauber konfigurieren kannst.

Die Route geht manchmal über Level3 und manchmal...

Falsche Beobachtung! Ein Traceroute besteht aus UDP-Paketen mit einem nicht existierendem Ziel. Bei den UDP-Paketen wird jeweils immer die TTL um eins nach oben gesetzt, bis das Ziel mit "Port Unreachable" antwortet. Der TTL beginnt dabei bei 1 und geht max. bis 30.

Für jeden TTL geht also ein eigenes Paket raus. Dein CISCO schickt nun manchmal dein UDP-Paket über ppp0 und einmal über ixp2 raus, womit du keine Kontrolle mehr hast.

217.237.152.174 = Im Netz von T-Com
4.68.23.139 = Peering-Partner von T-Com

Also beide Antworten mit Time-To-Life Exceeded kamen aus dem T-Com Backbone und nicht von Kabel-Deutschland!

Und hier ist der Bug: UDP: 500 geht an ppp0 raus (DTAG), UDP:4500 an ixp2 (KD) !!!! Sauberes Load-Balancing...

Korrekt, hier ist der Hund begraben! Über UDP Port 500 wird ein Handshake initialisiert, um zu wissen, ob man hinter einem NAT arbeitet, oder nicht. Der Tunnel wird letztendlich bei UDP 4500 geführt. Nun hast du zwei verschiedene Quell-IP-Adressen, die mit dem eigentlichem Handshake nichts zu tun haben. Also wird die Verbindung nicht akzeptiert.

Das Problem ist also auf deiner Seite zu suchen.

Wenn du wirklich Nach Ziel-Ports die WAN-Adresse bestimmen kannst, dann würde ich UDP 500 und UDP 4500 auf WAN2 (ixp2) jailen.

[Matze88]

Ein Traceroute besteht aus UDP-Paketen mit einem nicht existierendem Ziel.

es sollte aber schon das korrekte Ziel angegeben werden Der Abbruch wird nur durch eine zu geringe TTL erreicht.


Ich würde das Problem hier so lösen, dass die Ziel-IP des VPN fest über den KDG Anschluss geroutet wird, sofern dieser existent ist. Sofern es sich um eine dynamische Zuweisung handelt, müsstest du mal schauen, inwiefern du da weiterkommst... Mit Cisco habe ich bisher (leider & zum Glück) noch nichts gemacht
Ansonsten bleibt natürlich die vorgeschlagene Lösung, die Zielports statisch zu routen, wobei ich das für nicht ganz so sauber erachte. (Hierbei hätte ich auch noch die angst, dass Verbindungen mit zufällig diesem dynamischen Quellport aus dem Ruder laufen, wenn sie auf der anderen Leitung reinkommen. Oder hat hier der Eintrag in der TCP/UDP Verbindungstabelle grundsätzlich Vorrang?)

[RcRaCk2k]

es sollte aber schon das korrekte Ziel angegeben werden Der Abbruch wird nur durch eine zu geringe TTL erreicht.

Mit Ziel definiere ich einen UDP-Port Dass der HOST als ZIEL korrekt angegeben werden muss, davon gehe ich doch aus

[Christian S]

Da wir alle Ziel-Verbindungen mit festen IP-Adressen fahren, habe ich die Route zu diesem Kunden an ixp2 (KD) gebunden, jetzt klappt alles einwandfrei.

Christian

[RcRaCk2k]

Was habt ihr für Brutto- und Netto-Übertragungsraten?

KUNDE (Up / Down) ---- VPN SERVER (Up / Down)

Könnt ihr mal testen, ob ihr am Wochenende und Werktags (18-24Uhr) auch nur sehr geringe Bandbreite über euren Tunnel bekommt?

Ich habe am VPN-Server 1GiB / 1GiB und bei K.D. 32MiB / 2MiB, aber bekomme ab 18 Uhr nicht mehr als 4MiB im Down- und 2MiB im Up-Stream. Ab 24 Uhr gehen wieder ca. 30MiB im Download durch... (Aus der Sicht des K.D. Anschlusses).

[Christian S]

Was für ein Protokoll sollen wir für die Übertragung nehmen? FTP, HTTP, SMB? Wir schieben regelmäßig größere Datenmengen per FTP, ich werde mal auf die Uhrzeit achten.

Christian