FBF WLAN 7050: IPSec-VPN (UDP 500) wird nicht richtig durchgeleitet?

[telchef]

Hallo Spezis!

Die FBF WLAN 7050 leitet ja IPSec-VPN-Datenverkehr (UDP 500, ESP 50) nicht richtig durch, beherrscht also kein transparentes IPSec-Pass-Through (auch nicht für nur einen Client).

Weiß da jemand näheres drüber? (Infos von AVM / wird daran gearbeitet?)

Weiß jemand, ob wenigstens der unsichere PPTP-VPN-Datenverkehr (TCP 1723, GRE 47) möglich ist?


Gruß, Harald

 

[gerdshi]

Hallo!

Laut AVM sind dir Fritz!Boxen recht woll IPSEC-Passthrough freigegeben.
Wende dich an den AVM-Support fuer Hilfe, die schicken dir dann eine PDF-Datei. Aber eigentlich auch diese muesste es bei dir klappen, sobald du die entsprechende Ports freigeben hast. Wenn der Server hinter der Box steht. Am sonsten muesste es ohne weiteres funktionieren. Wie gesagt - laut AVM-Support.

Zum PPTP-Passthrough - jein. Zumidest bis vor einem Jahr war es von AVM nicht ofiziell freigegeben.
Folgendes passierte frueher:
1. Hinter einer Box kann von mehr als ein PC nur zu verschiedenen VPN-Server eine Verbindung aufgebaut werden. Sobald am zweiten PC eine Verbindung zum gleichen VPN-Server aufgebaut wird, bricht sie beim anderen PC ab.
2. Eingehende PPTP-VPN-Verindung klappen in der Regel reibungslos. Hatte noch nie Probleme, obwohl sich manche Leute hier in Forum beklagen.

Wieso du aber der Meinung bist, das PPTP-VPN (grundsaetzlich) unsicher ist, ist mir schleierhaft. Das es Protokolle gibt, die man ueber PPTP fahren kann und unsicher sind ist richtig, aber es gibt auch solche die definitiv sicher sind! Daher zu pauschalisieren... na ja. Dann kann man genau so gut auch sagen das SSH unsicher ist, nur weil Version 1 unsicher ist. ;-)

Gruss

 

[telchef]

Hallo gerdshi!

Danke für Deine Antwort. (Sie scheint aber auf einem Mißverständnis von Dir zu beruhen.)

Laut AVM sind dir Fritz!Boxen recht woll IPSEC-Passthrough freigegeben.
Wende dich an den AVM-Support fuer Hilfe, die schicken dir dann eine PDF-Datei.

Das werde ich trotzdem mal machen. (Erwarte allerdings eine falsche Antwort mit "Portweiterleitung", s.u.)

Aber eigentlich auch diese muesste es bei dir klappen, sobald du die entsprechende Ports freigeben hast. Wenn der Server hinter der Box steht.

Mißverständnis: Ich will keine Portweiterleitung (bei FBF fälschlicherweise "Portfreigabe" genannt) konfigurieren. GeNATete Clients sollen automatisch auf von innen aufgebaute Verbindungen antworten bekommen dürfen.

Portweiterleitung != IPSec-Pass-Through

Zum PPTP-Passthrough - jein. Zumidest bis vor einem Jahr war es von AVM nicht ofiziell freigegeben.
Folgendes passierte frueher:
1. Hinter einer Box kann von mehr als ein PC nur zu verschiedenen VPN-Server eine Verbindung aufgebaut werden. Sobald am zweiten PC eine Verbindung zum gleichen VPN-Server aufgebaut wird, bricht sie beim anderen PC ab.
2. Eingehende PPTP-VPN-Verindung klappen in der Regel reibungslos. Hatte noch nie Probleme, obwohl sich manche Leute hier in Forum beklagen.

Das ist ja armseelig.

(Aber es ist ja andererseits auch bekannt, daß AVM-Hardware für Mainstream- und Home-User-Anforderungen schon recht nett ist, bei der professionellen Umsetzung hapert es aber oft.)

Wieso du aber der Meinung bist, das PPTP-VPN (grundsaetzlich) unsicher ist, ist mir schleierhaft. Das es Protokolle gibt, die man ueber PPTP fahren kann und unsicher sind ist richtig, aber es gibt auch solche die definitiv sicher sind! Daher zu pauschalisieren... na ja. Dann kann man genau so gut auch sagen das SSH unsicher ist, nur weil Version 1 unsicher ist. ;-)
Gruss

Der Vergleich hinkt. PPTP läßt sich m.W. nicht sicher betreiben, im Gegensatz zu SSH (in V2); schon gar nicht im Windows-Umfeld.

Ich lasse mich aber gerne eines besseren belehren, und werde darauf mal erneut achten.


Gruß, Harald

 

[gerdshi]

Hallo!

Es ist kein Missverstaendniss!
Ich wollte nur ausfuerlich sein was eingehende Verbindung betrifft sein. Den das ist komplizierter zu realisieren.
Das Portwaeiterleitung nicht gleich Passthrough weiss jeder - habe auch nie das Gegenteil behauptet!
Am sonsten fuer ausgehene - wie gesagt - laut AVM geht das definitv und ist ofiziell freigegeben. Ob du bei dein Clients alles richtig eingestellt hast damit es am NAT des Router nicht happert... musst du wissen. Es ist etwas mehr als nur UDP-Packete zu verschicken. ;-)

Am sonsten wenn du bereits jetzt ein negatives Ergebnis von AVM erwartest, dann hat es auch kein Sinn die Leute damit zu beschaeftigen.

Was die mangehlafte PPTP-Unterstuetzunf der AVM betrifft - ja, leider war es so. Habe aber seit langem nicht mehr ausprobiert ob sich das ganze nicht vielleicht doch inzwischen verbessert hat!

Was den vergleich betrifft:
Wieso soll der Vergleich hinken? Du pauschalisierst, ich auch. Du sprichst ueber allte Protokolle die unsicher sind, ich auch. Wo hinkt es? ;-)
Was PPTP-betrifft - doch es geht auch sicher, Informiere dich per Google z.B. ueber MPE128 und MS-CHAP V2.
Also zumindest nicht ein mal die C't traut sich sowas zu behaupten was du geschrieben hast.
Wenn du aber unter 'unsicheres' PPTP meinst, das einfach IP-SEC eine straengere Verschluesserung benutzt und theoretisch shwiriger zu knacken ist - Ja, dann stimme ich dir voll zu. Aber unsicher ist eine sache (ohne grossen Aufwand komme ich rein wie z.B. bei SSH1), besser als etwas anderes zu sein, ist eine ganz andere Sache! ;-)

Und zur letzt - was besonders problematisch an deine Aussage ist - du machst eine Pauschalaussage ueber ein Protokoll welches gar keine Verschluesselung und Authentifizierung beihaltet, sondern nur eine Transportschicht darstellt ueber der man dann die notwendige Verschluesselungs- und Authentifizierungs-Protokolle 'faehrt' - nach eigenem Ermessen, Verantwortung, techn. Moeglichkeiten ...
Und was du dafuer benutzt ist dann auschlaggebend ob die Verbindung sicher ist oder nicht - nicht alleine PPTP an sich. ;-)
Nur das hat mich gestoert. Nicht fuer ungut. ;-)

Gruss
P.S. AVMs Antwort vom 27.01.2005:
Sehr geehrter Herr xxxxx,

vielen Dank fuer Ihre Anfrage.

Die Produkte der FRITZ!Box-Familie unterstuetzt im Betrieb als DSL-Router
IPSec-VPN mittels Passthrough-Verfahren.

Folgende Hinweise zur Funktionalitaet sind dabei jedoch zu beachten, welche sich aber grundsaetzlich mit jedem VPN-Passthrough-faehigen NAT-Geraet (Router) ergeben:

Die Nutzung des automatischen Auf- und Abbaus der DSL-Internetverbindung nach Bedarf (aktivierter Timer) ist nur eingeschraenkt moeglich. Da der VPN-Client den Abbau der Internetverbindung nicht mitbekommt, wird nach dem Wiederaufbau der Internetverbindung die notwendige Neuaushandlung der VPN-Verbindung unter Umstaenden nicht neu angestossen.

Die Neuaushandlung ist aber notwendig, da bei den meisten ISPs bei jeder
Einwahl eine andere oefentliche IP-Adresse vergeben wird und diese dem
entfernten VPN-Gateway dann jedoch nicht bekannt ist.

Bei Nutzung des VPN-Protokolls "IPSec" steht der IPSec-Modus
"Authentication Header" (AH) nicht zur Verfuegung. Die Nutzung des ohnehin
wichtigeren IPSec-Protokolls "ESP" ist jedoch problemlos moeglich. Die
Nutzung von PPTP ist denkbar, wurde von AVM jedoch nicht getestet. Die
Funktion wird somit nicht zugesichert.

Bei Nutzung des VPN-Protokolls "IPSec" kann maximal ein Client gleichzeitig
zum selben VPN-Gateway eine Verbindung aufbauen.

Die hier genannten Einschraenkungen sind prinzipbedingt und gelten fuer die
im Handel erhaeltlichen NAT-Geraete. Die Einschraenkungen gelten nur dann
nicht, wenn Ihre eingesetzte VPN-Loesung das relativ neue
IPSec-NAT-Traversal-Protokoll unterstuetzt.
Spezielle Einstellungen auf Seiten der FRITZ!Box sind nicht notwendig.

Mit freundlichen Gruesse

 

[frank_m24]

Hallo,

1. Hinter einer Box kann von mehr als ein PC nur zu verschiedenen VPN-Server eine Verbindung aufgebaut werden. Sobald am zweiten PC eine Verbindung zum gleichen VPN-Server aufgebaut wird, bricht sie beim anderen PC ab.

Das ist nicht armseelig, sondern normal, siehe RFC 2637:
"The PPTP RFC specifies in section 3.1.3 that there may only be one control channel connection between two systems. This should mean that you can only masquerade one PPTP session at a time with a given remote server."

Sprich: kein Router kann das.

Mißverständnis: Ich will keine Portweiterleitung (bei FBF fälschlicherweise "Portfreigabe" genannt) konfigurieren. GeNATete Clients sollen automatisch auf von innen aufgebaute Verbindungen antworten bekommen dürfen.

Portweiterleitung != IPSec-Pass-Through

Ich versteh kein Wort. Was heißt "Antworten bekommen dürfen?" Dass die Verbindung bidirektional ist? Dass Server eine Rückverbindung aufbaut, eine Art Callback? Was genau willst Du, welche Anwendung/Use cases?
Dass Portweiterleitung nichts mit VPN Passthrough zu tun hat, ist klar. Deshalb schreibt gerdshi ja auch von dem Betreiben eines VPN Servers hinter der Box, dafür braucht man sehr wohl eine PortWEITERLEITUNG (nur, damit du nicht meckerst ).

Übrigens: Der kommerzielle Cisco VPN Client oder die OpenSource Variante VPNC läuft problemlos hinter der Fritzbox.

PPTP ist nicht grundsätzlich unsicher. Nur dass häufig (aber nicht zwangsläufig) für die Nutzerauthentifizierung eingesetzte MSChapV2 hat eine Schwachstelle, die die Anzahl der in Frage kommenden Passwörter um den Faktor 2 hoch 16 reduziert (http://www.heise.de/newsticker/meldung/19544, http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/). MSChapV2 kommt aber auch bei L2TP over IPSec und WPA/WPA2 zum Einsatz (allerdings über eine bereits verschlüsselte Verbindung. Hoffentlich jedenfalls im Falle von WPA, denn es geht auch über eine unverschlüsselte WLAN Verbindung, wenn man kein RADIUS Server Zertifikat nutzt).

Viele Grüße

Frank

 

[gerdshi]

Hallo!

Das ist nicht armseelig, sondern normal, siehe RFC 2637:
"The PPTP RFC specifies in section 3.1.3 that there may only be one control channel connection between two systems. This should mean that you can only masquerade one PPTP session at a time with a given remote server."

Sprich: kein Router kann das.

Bist du dir sicher? Ich meine die Auslegung des RFC ansich?
Denn dann ist es verwunderlich wie es die Router von Bintec, Draytek und Linksys das definitiv fehlerfrei hinkriegen. (Andere sicher auch.)
Was ist wirklich unter 2-Systeme gemeint? Ich denke die rede ist ueber Endpunkte - und der Router ist trotz NAT aber kein Endpunkt. Nach deiner Auslegung waere sommit unmoeglich eine Verbindung zwischen Client und Server zu machen die beide hinter NAT sind. Den dann ist bereits der interne Router an sich das 2te-Sytem.
PPTP = Point-to-Point-Tunneling-Protokoll?!
IMHO ;-)

Gruss
P.S. Ich sehe das du ein Draytek hast - er als PPTP-Client ist natuerlich schon gleichzeitig Router und Endpunkt. ;-)

 

[KuniGunther]

Die FBF WLAN 7050 leitet ja IPSec-VPN-Datenverkehr (UDP 500, ESP 50) nicht richtig durch, beherrscht also kein transparentes IPSec-Pass-Through (auch nicht für nur einen Client).

Die Info wird dir zwar erst mal nicht weiterhelfen, aber bei mir (Cisco VPN Client) funktioniert das in genau dieser Konfiguration (IKE über UDP 500, IPSec mit ESP Header). Die 7050 kann das also eindeutig, und zwar ohne jede weitere Konfiguration meinerseits. (Die 7050 unterstützt auch Portforwarding für ESP, für den Fall das man einen VPN-Server betreiben will!)

Die Frage ist, wo scheitert es denn? Schon beim Key-Exchange oder erst bei der Verbindung? Du bist sicher, dass ESP und nicht AH benutzt wird? Blockiert die 7050 aus anderen Gründen (z.B. Port 500 anderweitig umgeleitet)?

Wenn Du es Dir leisten kannst (von wegen Aufwand), kannst Du die 7050 in den Auslieferungszustand zurücksetzen und es so mal probieren.

Der Cisco Client/Server bietet alternativ transparentes Tunneln über UDP und TCP an, so dass man auch aus Netzen, deren Firewall oder NAT kein IPSec können, ins Heimnetz kommt. Hast Du vielleicht ähnliche Möglichkeiten, die Du checken kannst?

Volker

 

[frank_m24]

Hallo,

Bist du dir sicher? Ich meine die Auslegung des RFC ansich?
Denn dann ist es verwunderlich wie es die Router von Bintec, Draytek und Linksys das definitiv fehlerfrei hinkriegen. (Andere sicher auch.)

Ja, da bin ich mir sicher. Und gerade die von dir angesprochenen Draytek Router können es nicht (Vigor 2500 und 2200 selbst getestet, bei 2. Verbindung fliegt der erste raus), der Siemens SE515 meines Vaters kann es nicht (da kann man keine zweite Verbindung aufbauen, Windows meldet "Modem Fehler") und hinter Routern, die auf Windows Server 2003 basieren geht es auch nicht (die zweite Verbindung melden ebenfalls Modemfehler). Sollte irgend ein Router es doch versuchen, so verletzt er die RFC und man handelt sich Kompatiblitätsprobleme ein.

Was ist wirklich unter 2-Systeme gemeint? Ich denke die rede ist ueber Endpunkte - und der Router ist trotz NAT aber kein Endpunkt. Nach deiner Auslegung waere sommit unmoeglich eine Verbindung zwischen Client und Server zu machen die beide hinter NAT sind. Den dann ist bereits der interne Router an sich das 2te-Sytem.
PPTP = Point-to-Point-Tunneling-Protokoll?!

Alle NAT-Clients erscheinen im Internet mit der öffentlichen IP Adresse des Routers, ein Server kann zwei hinter einem NAT Router befindliche Geräte nicht auseinander halten. Er spricht nur mit dem Router. Der Router seinerseits frickelt die Pakete anhand seiner Routing/Port Tabelle wieder auseinander und lässt sie dem entsprechenden Client zukommen, weil er die Kenntnis über die aktiven Verbindungen seiner Clients hat. Deshalb ja auch die Unterscheidung zwischen privaten und öffentlichen IP Adressen: Die privaten werden im Internet nicht geroutet, weil es sie ja auch vielfach gibt (Was meinst Du, wie oft es den Rechner mit der IP 192.168.0.1 gibt ). Ein Server KANN also gar nicht wissen, wo er genau diesen privaten Rechner zu suchen hat, also spricht er mit dem öffentlich Erreichbaren: Dem Router.

Wen auch der Server hinter NAT ist: Dann muss es eine entsprechende Portweiterleitung durch den NAT Router auf den Server geben, das geht nur einmal pro Router (und damit pro öffentlicher Adresse). Im Client gibt man dann auch als Ziel für die VPN Verbindung die öffentliche Adresse des Routers an und nicht die private des VPN Servers (siehe meine Ausführung oben).

Wenn man vorhat, mehrere Rechner aus einem Netz über VPN mit einem anderen Netz zu verbinden, dann sollte man ein spezielles VPN Gateway dafür verwenden, also nur eine Verbindung für alle.
Das kann z.B. ein Draytek Router sein, die können das, da geht dann alles von allein. Aber auch ein ganz gewöhnlicher Windows oder Linux Rechner kann die Rolle übernehmen, selbst hinter einem Router. Der Rechner baut einfach die VPN Verbindung auf und dient allen Clients (und auch sich selbst) als Gateway für das Zielsubnetz. Z.B. mit der "Internetverbindungsfreigabe" von Windows habe ich sowas schon selbst mal aufgebaut.

Viele Grüße

Frank

 

[gerdshi]

Hallo!

Tut mir leid - nichts fuer ungut. Entweder hast du was falsh getestet oder etwas nicht verstanden!
Es geht definitiv mit sowohl 2200x, als auch vorher mit 2300 in zusammenhang mit dem im Windows 2000 (bei eine anderen Firma am Win2003) intergrierten VPN-Server. Aboslut sauber seit ueber ein 1,5 Jahr! Verschiedene PCs im Netz des Draytek verbinden sich mit einen und den selben VPN-PPTP-Server (wie gesagt auf MS-Windows Basis) im Internet. In der Regel gleichzeitig, manchmal auch zeitlich versetzt. Und das funktioniert 100%! Ob du es glaubst oder nicht - ohne Verbindungs abbrueche.
Die Meldungen die du bekommst habe ich noch nie bekommen und daher denke ich, das ein Missverstaendnis vorliegt und wir ueber verschiedene Sachen reden. Denn du bist definitiv der erste der behauptet das hinter ein NAT-Netz die PCs sich nie zu einem und den gleichen VPN-Server zum gleichen Zeitpunkt verbinden koennen.
Ob das eine RFC Verletzung - bezweifele ich das, den genau dafuer ist das PPTP gedacht - eine Punkt-zu-Punkt Verbindung unabhaengig davon wo die Pakete entlang gehen - also unabhaengig von Router und Bridges! Auch im RFC wird genau ueber Systeme im Sinne von Endpunkte und nicht Router gesprochen. Es wird nicht das Wort Endpunkt benutzt, da es bei VPN grundsaetzlich um Netze handelt die am beiden Ende sind. Im Fall eines PC, wo das Netz der PC selbst, denke ich darf mir die freiheit erlauben und ueber Enpunkten zu sprechen. Wo der Trafik Verlaueft ist absolut nicht bestandteil des PPTP-RFC.


Komplizierter Wird es dagegen wenn hinter ein NAT-Router mehrere VPN-Server liegen. Ok, das wird nicht gehen. Aber das war auch nicht die Frage des Fragestellender. Zugegeben im bezug von IP-SEC und nicht PPTP, aber immerhin.

Alle NAT-Clients erscheinen im Internet mit der öffentlichen IP Adresse des Routers, ein Server kann zwei hinter einem NAT Router befindliche Geräte nicht auseinander halten.

Tut mir leid aber das ist absoluter Unsinn! Ein Klient baut die Verbindung zum Server und nicht umgekehrt. Bemerke auch das es ueber TCP-Port 1723 geht. Und ueber diesen Kanal werden die Daten dann ausgetauscht.
Der Router ist dafuer da, sich zu merken von welchem Klient zu welchem Server die Daten gehen und zurueck ueber den gleichen Kanal.
Das hast du bereits ganz gut beschrieben. Das ganze hat aber nichts mehr mit PPTP zu tun. Es ist nicht mehr bestandteil des PPTP sondern von Routing Protokoll. Bitte nicht die Themen vermischen bzw. verwechseln.

Tatsache ist, das es geht. Tatsache ist, das ich kein verstoss im RFC zu dem was ich selbst beobachtet habe und benutze, erkennen kann. Aber auch wenn es doch ein verstoss gegen des RFC sein soll, meinetwegen - es geht.

Ich hoffe ich muss dir kein Zugang zu den Firmennetzen (wo das laeuft) zu gewaerleisten damit du dich selbst ueberzeugen kannst?! ;-)

Uebrigens das was du beschreibst, entspricht ziemlich genau der Problematik bei IPSec ohne das IPSec-NAT-Traversal-Protokoll. Denn dort werden die Pakete per UDP vom Server verschickt und wird grundsaetzlich mit reele IP-Adressen gearbeitet und es ist in der Tat sehr schwer eingehende UDP-Verbindung zum IP-Sec Klient hinter NAT zu zuordnen. Daher wurde auch dieses Traversal-Protokoll eingefuehrt, damit es auch hinter NAT klappt.

Gruss

 

[frank_m24]

Hallo,

Ich fürchte, ich muss dir doch in einigen Punkten wiedersprechen.

Hinter den von mir genannten Routern kann man definitiv nicht zwei PPTP gleichzeitig von zwei CLients zum selben Server aufbauen. Ich war bereits mehrfach mit einem Kollegen bei einem Kunden, der uns über einen DSL Router (ein Vigor) den Internetzugriff erlaubt hat, damit wir unsere eMails abrufen können etc. Wir haben beide ein Notebook, VPN Verbindung zu unserer Firma über PPTP. Und da passiert genau das, was ich beschrieben habe: An einem Vigor fliegt der erste raus, sobald der 2. die Verbindung aufbaut. Bei dem Siemens Router meines Vaters habe ich es mit einem PC und einem PocketPC selbst mal getestet: Die zweite Verbindung erzeugt einen Modemfehler, auf beiden Geräten.

Ich bin übrigens nicht der erste, der das behauptet! Such mal bei google nach 2 PPTP gleichzeitig zum selben Server, du findest tausende Fehler diesbezüglich. (siehe auch z.B. hier: http://www.clarkconnect.com/wiki/in..._With_Two_PPTP_Connections_to_the_Same_Server)


Fakt ist, dass ein NAT Router auch bei einer PPTP Verbindung dem VPN Server gegenüber die Rolle als Client einnimt. Sieh dir die Logs von von VPN Servern an, die Verbindungsrequests kommen von der öffentlichen IP des Routers, nicht von der privaten des Cleints. Dass der Tunnell dann natürlich am Client-PC endet, ist klar. Aber woher soll der VPN Server das wissen? Er spricht 2 mal mit dem Router, hat also 2x einen Controlchannel mit derselben IP. Und es ist, wie schon erwähnt, auch nicht erlaubt. Ich zitieren die RFC:

"A PAC and PNS must have only one control connection between them."

Anmerkung PAC: PPTP Access Concentrator, PNS: PPTP Network Server. Der Begriff "Access Concentrator" läßt schon erahnen, das es sich nicht um einen Client im eigentlichen Sinn handelt.

Und wie du schon sagst: Wie die Pakete laufen (also was der Router damit macht), ist nicht Bestandteil der PPTP RFC, genau deswegen geht es ja nicht, wel eben der VPN Server gar nicht mitkriegt, dass er mit einem Router redet anstatt mit einem PC.

Alle NAT-Clients erscheinen im Internet mit der öffentlichen IP Adresse des Routers, ein Server kann zwei hinter einem NAT Router befindliche Geräte nicht auseinander halten.

Tut mir leid aber das ist absoluter Unsinn! Ein Klient baut die Verbindung zum Server und nicht umgekehrt.

Das ist kein Unsinn. Es hat überaupt nichts mit Verbindungsauf- und abbau zu tun, sondern lediglich mit dem Umstand, wie ein Server mit seinen Clients kommuniziert. Er weiß nichts von den Clients hinter einem NAT-Router. Er spricht mit dem Router und fertig. Alles andere ist das Problem des Routers. Es ist nicht PPTP spezifisch und war auch nicht so gemeint, trifft aber auch auf PPTP zu, denn die Routing Mechanismen sind nicht extra für PPTP verändert worden.

Andererseits verstehe ich die ganze Aufregung nicht. Es ist eigentlich genau wie du sagst:

.. da es bei VPN grundsaetzlich um Netze handelt die am beiden Ende sind.

Deshalb ist technisch eigentlich schon völliger Unfug, hinter einem NAT Router 2 VPN Verbindungen gleichzeitig zum selben Server aufzubauen. Eine erfüllt den Zweck vollständing und ist auch keine RFC Verletzung. Der VPN Client fungiert als Gateway und fertig (So wird es übrigens im Linux Masquerading Howto empfohlen).

Das mit dem IPSEC über NAT kann ich nur voll Unterstützen, vor allem, da mein Vigor kein NAT-Traversal kann . Ich muss also PPTP nutzen, wenn ich mich von unterwegs mal schnell zu Hause einklinken will.

Wie problematisch solche vom Server initiierten Rückverbindungen sein können, sieht man ja schon am harmlosen FTP: Hinter einem NAT Router braucht man möglicherweise Passive FTP, bei dem der Client die eigentliche Verbindung für den Dateitransfer initiiert. Bei Active FTP baut nämlich der Server diese Verbindung auf (zu der öffentlichen IP des Routers), und einige NAT Router verwerfen diese, weil sie nichts damit anfangen können, sie wissen halt nicht wohin damit. Da wundert sich der Nutzer dann, wieso er den FTP Server connecten kann, die Verzeichnisse sieht und nur der Download an sich dann plötzlich einfach nicht anfängt. Nur die Router mit Stateful Traffic Inspection können diese Verbindung einem Client zuordnen, da geht dann auch Active FTP über NAT.

Viele Grüße

Frank

 

[telchef]

Hallo gerdshi!

(Na, das Thema ist ja ganz schön umfangreich geworden. Hier mal die Antwort auf Dein Posting vom 13.01.2006, 20:49.)

Das Portwaeiterleitung nicht gleich Passthrough weiss jeder - habe auch nie das Gegenteil behauptet!

Ok.

(Hörte sich aber so an, weil Du folgendes geschrieben hattest:
"Aber eigentlich auch diese muesste es bei dir klappen, sobald du die entsprechende Ports freigeben hast."
Und das ist eindeutig "Portweiterleitung". Allerdings bist Du offenbar davon ausgegengen, daß der VPN-Server/das VPN-GW hinter der FBF sitzt, und nicht der Client, was ja eher selten sein dürfte, da die FBF ein billiges Home-User-Produkt ist, hinter die wohl nur Hobbyisten "Server" stellen. Der typische Anwendungsfall dürfte sein, daß ein hinter der FBF sitzender Road-Warrior etwas tun will.)

Am sonsten fuer ausgehene - wie gesagt - laut AVM geht das definitv und ist ofiziell freigegeben.

Bis jetzt konnte ich noch keinen Weg finden. Freue mich schon auf das PDF von AVM, muß aber erstmal eine präzise Fehlerbeschreibung fertigstellen, damit ich von denen keine falsche/unpassende Standardantwort bekomme.

Ob du bei dein Clients alles richtig eingestellt hast damit es am NAT des Router nicht happert... musst du wissen. Es ist etwas mehr als nur UDP-Packete zu verschicken. ;-)

Nein, da habe ich alles falsch eingestellt. Ich bin auch sonst zu blöde. Ist auch meine erste IPSec-Installation... ;-))

Im ernst: Mit zwei anderen wertigeren DSL-Routern an der selben Stelle (also keinerlei Konfigurationsänderung, nur Tausch der FBF gegen anderen Router) klappt es einwandfrei.

Am sonsten wenn du bereits jetzt ein negatives Ergebnis von AVM erwartest, dann hat es auch kein Sinn die Leute damit zu beschaeftigen.

Ähem...

Ich gebe die Hoffnung nicht auf. Und schließlich kann nur AVM diese Einschränkung aufheben.


Zum Thema Sicherheit von PPTP:
Jaja, ich habe ja gesagt, daß ich das in Zukunft (auf Deine Einschätzung hin) nochmal genauer betrachten will. Also nix für ungut.



Zu AVMs Antwort:

Die Produkte der FRITZ!Box-Familie unterstuetzt im Betrieb als DSL-Router
IPSec-VPN mittels Passthrough-Verfahren.

Wie gesagt: Ich kann das bisher nicht erkennen.

Da es sofort geht, sobald ich eine Portweiterleitung (FBF-Jargon "Portfreigabe") von UDP 500 zu meinem Test-Client im internen Netz setze, zeigt mir auch eindeutig, daß hier eben genau kein Pass-Through möglich ist.

Bei Nutzung des VPN-Protokolls "IPSec" kann maximal ein Client gleichzeitig
zum selben VPN-Gateway eine Verbindung aufbauen.

Nicht mal einer!

Und das mag dann noch für die FBF gelten. Andere Router können problemlos mehrere IPSec/ESP-VPN-Clients vom internen, geNATeten Netz an ein im Internet erreichbares IPSec-VPN-Gateway verbinden.
(Und da ist kein NAT-T im Spiel.)

Die hier genannten Einschraenkungen sind prinzipbedingt und gelten fuer die
im Handel erhaeltlichen NAT-Geraete. Die Einschraenkungen gelten nur dann
nicht, wenn Ihre eingesetzte VPN-Loesung das relativ neue
IPSec-NAT-Traversal-Protokoll unterstuetzt.
Spezielle Einstellungen auf Seiten der FRITZ!Box sind nicht notwendig.

Selbst wenn NAT-T im Spiel wäre: Da es mit anderen Routern in der selben Installation klappt (FBF gegen anderen Router ausgetauscht), nur mit der FBF nicht, würde das auch nicht helfen.


Soweit erstmal. Ich bleibe dran und berichte.


Gruß, Harald

P.S. Ich war etwas unpräzise mit meiner Beschreibung, was überhaupt gewünscht ist. Da die FBF allerdings ein typisches Home-User/Home-Office- bzw. 1-Mann-Office-Teil ist, erschien mir die genaue Erklärung eines aus meiner Sicht üblichen Anwendungsfalls nicht erforderlich - besonders, da es ja auch nur um das nicht funktionierende Feature IPSec-Pass-Through geht, das ja eher unabhängig vom Anwendungsfall ist.

Hier mal nachgereicht:
- im Internet direkt über öffentliche IP erreichbares IPSec-VPN-Gateway
in ein Firmennetz
- Home-Office mit FBF
- Notebook (Road-Warrior) mit VPN-Client-Software im geNATeten
internen LAN hinter der FBF

Ohne weitere Konfiguration sollen beliebige dieser Notebook-Road-Warrior mit ihren im internen LAN der FBF wechselnden DHCP-Adressen transparent mit ihrem IPSec-Datenverkehr durch die FBF kommen.

 

[telchef]

Hallo KuniGunter!

Die Info wird dir zwar erst mal nicht weiterhelfen, aber bei mir (Cisco VPN Client) funktioniert das in genau dieser Konfiguration (IKE über UDP 500, IPSec mit ESP Header). Die 7050 kann das also eindeutig, und zwar ohne jede weitere Konfiguration meinerseits.

Interessant!
Und Du bist ganz sicher, daß keinerlei Portweiterleitung (FBF-Jargon "Portfreigabe") eingestellt ist!? Ganz sicher!?

(Die 7050 unterstützt auch Portforwarding für ESP, für den Fall das man einen VPN-Server betreiben will!)

Ja, ist mir bewußt. (Danke trotzdem, man kann ja nicht präzise genug sein.)

Die Frage ist, wo scheitert es denn? Schon beim Key-Exchange oder erst bei der Verbindung? Du bist sicher, dass ESP und nicht AH benutzt wird? Blockiert die 7050 aus anderen Gründen (z.B. Port 500 anderweitig umgeleitet)?

Schon beim Key-Exchange.
Ja, ESP.
Nein, TCP-Port 500 nicht anderweitig weitergeleitet.

Es sieht so aus, als kämen die Antworten vom VPN-Gateway im Internet auf dem Rückweg nicht richtig durch die FBF zum angeschlossenen Client-PC.
Habe das aber noch nicht 100%ig analysiert.

Wenn Du es Dir leisten kannst (von wegen Aufwand), kannst Du die 7050 in den Auslieferungszustand zurücksetzen und es so mal probieren.

Weiß nicht genau, was das bringen soll. (Ok, kann manchmal helfen bei fehlerhaften Systemen.)
Im Grunde kam er vom Auslieferungszustand.

Der Cisco Client/Server bietet alternativ transparentes Tunneln über UDP und TCP an, so dass man auch aus Netzen, deren Firewall oder NAT kein IPSec können, ins Heimnetz kommt. Hast Du vielleicht ähnliche Möglichkeiten, die Du checken kannst?

Was meinst Du damit genau? Ein Tunneln des gesamten IPSec-Verkehrs z.B. durch TCP-Port 80? Sozusagen eine integrierte -aber logisch vorgeschaltete- 2. VPN-Tunnel-Lösung ohne Verschlüsselung, durch die der echte Tunnel getunnelt wird?

Nein, sowas kann ich nicht.


Gruß, Harald

 

[telchef]

Hallo frank_m24!

Nur mal dieses Detail betrachtet:

Deshalb ist technisch eigentlich schon völliger Unfug, hinter einem NAT Router 2 VPN Verbindungen gleichzeitig zum selben Server aufzubauen. Eine erfüllt den Zweck vollständing und ist auch keine RFC Verletzung. Der VPN Client fungiert als Gateway und fertig (So wird es übrigens im Linux Masquerading Howto empfohlen).

Du widersprichst Dir im selben Posting, weil Du genau die typische Road-Warrior-Konfiguration selber benutzt, die dieses technische Möglichkeit verlangt (und mit IPSec geht es, habe ich selber in mehreren Installationen):

Hinter den von mir genannten Routern kann man definitiv nicht zwei PPTP gleichzeitig von zwei CLients zum selben Server aufbauen. Ich war bereits mehrfach mit einem Kollegen bei einem Kunden, der uns über einen DSL Router (ein Vigor) den Internetzugriff erlaubt hat, damit wir unsere eMails abrufen können etc. Wir haben beide ein Notebook, VPN Verbindung zu unserer Firma über PPTP. Und da passiert genau das, was ich beschrieben habe: An einem Vigor fliegt der erste raus, sobald der 2. die Verbindung aufbaut. Bei dem Siemens Router meines Vaters habe ich es mit einem PC und einem PocketPC selbst mal getestet: Die zweite Verbindung erzeugt einen Modemfehler, auf beiden Geräten.

Gruß, Harald

 

[gerdshi]

Hallo!

@frank_m24
Was verstehst man nicht an der Aussage ES GEHT (bei zwei Kunden von mir) DOCH!?!
Das du etwas falsch machst ist eine Sache, das es nicht gehen kann aber eine ganz andere.

Fuer mich hat sich das Thema erledigt - bei mir geht es und da es zwei firmen Netze sind fuer die ich einfach nicht das Recht habe dir ein Zugang zu gewaehrleisten um dich selbst zu Ueberzeugen, macht es kein Sinn weiter das zu diskutieren. Meinetwegen sag das ich Voodoo mache. ;-)

Nur ein kleiner Tip von mir - informiere dich wieso PPTP ueber TCP laeuft, was Point-to-Point und PPTP-Passthrough bedeuten.

Gruss

P.S. Ich gebe zu das frueher SMC-Router maechtig Probleme hatten sogar ein PPTP-Kanal aufzubauen obwohl sie angeblich als PPTP-Passthrough freigegeben waren. Es stellte sich heraus das es ein Bug war. Inzwichen koennen es die meisten (bis 2-3 Jahre alte). Darunter auch der SMC2804WBR - damit verlief der Test auch fehlerfrei. Habe es auch bei einem Freund wegen dein Posting noch mal versucht, mit seinem SMC. Tut mir leid - geht auch. Zugegeben dort habe ich es mit nur 2 PCs getestet - mehr standen nicht zur Verfuegung.

 

[frank_m24]

Hallo,

Wie gesagt, suche mal bei Google zu dem Thema, und du wirst schnell feststellen, dass es häufig nicht geht. (http://www.google.de/search?sourcei...=multiple+PPTP+Connections+to+the+Same+Server)

Außerdem verlangt die Spezifikation, das es nicht geht. Siehe den Link, den ich in meinem letzten Posting untergebracht habe.

Viel falsch machen kann man nicht, wenn man einfach nur zwei PPTP Clients, die unabhängig hervorragend funktionieren, hinter einem NAT-Router zeitgleich verbindet. Und da treten die von mir beschriebenen (und im Internet nachvollziehabren) Effekte halt auf. Was ist daran so schwierig zu verstehen?

@telchef: Mein Kollege und ich haben halt jeder ein Notebook mit konfiguriertem VPN Zugang, wir sind zuweilen gemeinsam unterwegs. Bei unserem Kunden wollen wir natürlich nicht den VPN Zugang im Router einrichten, schließlich soll er ja nicht in unserem Netz werkeln können. Also zwei PPTP Clients hinter dem Router. Wenn es dann zufällig zu der Situation kam, dass beide gleichzeitig versucht haben, ihre Mails abzurufen, so traten die Effekte auf.
Die Tests mit dem PocketPC und meinem PC habe ich nur gemacht, um die Router bei mir und bei meinem Vater zu testen. Die Probleme mit dem auf Windows 2003 basierenden Router hat mir unser Sysadmin gezeigt.

Mit IPSEC geht es übrigens wirklich problemlos, zumindest für die Cisco VPN Clients und deren Opensource Variante VPNC kann ich das bestätigen.

Übrigens: Ich weiß, was Point-to-Point und PPTP-Passthrough bedeutet, auch was z.B. Linux iptables mit PPTP Connection Tracking und Stateful Traffic Inspection macht.

Ich denke aber auch, dass wir die Diskussion hier beenden sollten. Es scheint tatsächlich Produkte zu geben, die versuchen, diesen Nachteil der PPTP RFC zu umgehen. Schließlich arbeitet ja auch das PPTP Connection Tracking von iptables in diese Richtung. Möglicherweise sind ja auch die VPN Server die Ursache für die Probleme. Schließlich muss nicht nur der Router, sondern auch der VPN Server mit 2 Controlchanneln vom selben Client zurecht kommen, und es ist einfach nur unser Cisco 3000 VPN Concentrator, der es nicht beherrscht.

//EDIT: Habe grade mal ein anderes Szenario aufgebaut. Ich habe einen PPTP Zugang in meinem Vigor 2500 eingerichtet (Server) und dann hinter dem Siemes SE515 meines Vaters 2 PPTP Verbindungen dahin aufgebaut (PocketPC und PC). Siehe da: es geht. 10 Sekunden Später 2 Verbindungen zum Cisco 3000 unserer Firma: Modemfehler bei der zweiten Verbindung. Es ist also tatsächlich der VPN Server, der den Ärger macht. //EDIT off


Viele Grüße

Frank

 

[KuniGunther]

Hallo Harald,

Und Du bist ganz sicher, daß keinerlei Portweiterleitung (FBF-Jargon "Portfreigabe") eingestellt ist!? Ganz sicher!?

Ja, ganz sicher Meine Liste ist leer, nur für den Fall, dass eMule mal laufen sollte, wird da was eingeschaltet.

Schon beim Key-Exchange.
Ja, ESP.
Nein, TCP-Port 500 nicht anderweitig weitergeleitet.

Wenn das schon beim Key-Exchange schief läuft, dann hat das nichts mit ESP und eigentlich auch nichts mit IPSec speziell zu tun.

Der Key Exchange läuft beidseitig über reines UDP, Port 500, also noch keine "IPSec"-Pakete (mal lax ausgedrückt). Und da die Verbindung von Deiner Seite aus aufgemacht wird, sollten FBF und Windows Firewall kein Problem machen.

Hast Du schon mal probiert, die Fritzbox nur als DSL-Modem zu nutzen? Oder Deinen Rechner mal als exposed host einzutragen (natürlich nur testweise). Und dann z.B. mit ethereal mal schauen.

Es sieht so aus, als kämen die Antworten vom VPN-Gateway im Internet auf dem Rückweg nicht richtig durch die FBF zum angeschlossenen Client-PC.
Habe das aber noch nicht 100%ig analysiert.

Ich denke, das wäre dann aber nötig.

Bzgl. Tunneln:

Was meinst Du damit genau? Ein Tunneln des gesamten IPSec-Verkehrs z.B. durch TCP-Port 80? Sozusagen eine integrierte -aber logisch vorgeschaltete- 2. VPN-Tunnel-Lösung ohne Verschlüsselung, durch die der echte Tunnel getunnelt wird?

So in etwa. Ich kann da zwischen UDP und TCP wählen und dann werden alle IPSec-Pakete nochmal eingepackt, in normalen "IP" Paketen übers Netz geschickt und vom VPN-Server wieder ausgepackt. Hört sich überflüssig an, aber hat mir schon öfter unterwegs geholfen.

Viele Grüße,
Volker

 

[KuniGunther]

Hallo nochmal,

Da es sofort geht, sobald ich eine Portweiterleitung (FBF-Jargon "Portfreigabe") von UDP 500 zu meinem Test-Client im internen Netz setze, zeigt mir auch eindeutig, daß hier eben genau kein Pass-Through möglich ist.

Hmm, genau das hat auch semilla in einem anderen Thread anderen Thread bestätigt. Offenbar funktioniert es bei mir zufällig, da der Cisco VPN Server, der bei uns eingesetzt wird, wohl auch IKE macht, wenn dieses nicht über UDP500, sondern einem anderem Port reinkommt (nehme ich jetzt wenigsten mal an). Das verstehe ich allerdings nicht unter funktionierendem IPSec Pass-Through.

Heißt also: Bei AVM mal gezielt nachhaken was IKE angeht.

Viele Grüße
Volker

EDIT: Ich habe nach einem Vorschlag die ausgehenden Pakete der Fritz gecaptured und geschaut, was das Portforwarding macht. Ergebnis: Es kann eigentlich nicht sein, dass der Client mit Portforwarding von Port 500 geht und ohne nicht, da es keinen Unterschied in der ausgehenden Verbindung gibt. In beiden Fällen findet kein Pass-Through statt, sondern Source Port 500 wird auf einen anderen umgesetzt.

Dafür weiß ich jetzt, dass ich gar nix mehr weiß ...

EDIT 2: Offenbar war beim Capturen was schiefgelaufen oder die Box hat das Forwarding nicht gesetzt: Portforwarding verhindert das Port-Umschreiben, was auch von AVM bestätigt wird.

 

[telchef]

Hallo Volker!

Wenn das schon beim Key-Exchange schief läuft, dann hat das nichts mit ESP und eigentlich auch nichts mit IPSec speziell zu tun.

Der Key Exchange läuft beidseitig über reines UDP, Port 500, also noch keine "IPSec"-Pakete (mal lax ausgedrückt). Und da die Verbindung von Deiner Seite aus aufgemacht wird, sollten FBF und Windows Firewall kein Problem machen.

Ja, da hast Du wohl recht. Umso peinlicher, daß UDP-500-Antworten auf Anfragen des geNATeten Clients hinter der FBF nicht wieder von der FBF zurückgelassen werden.
Man könnte da ja sogar behauten, daß das NAT nicht richtig funktioniert. Ich will mich aber ohne weitere Traffic-Analysen hier eigentlich nicht zu weit aus dem Fenster lehnen. Vielleicht habe ich ja was falsch beobachtet/interpretiert. (Allerdings mit mehreren verschiedenen Clients und OSsen: eher unwahrscheinlich)

Hast Du schon mal probiert, die Fritzbox nur als DSL-Modem zu nutzen?

Das ist dann ja transparent. Bringt also nichts.
(Unabhängig davon hatte ich natürlich auch schon diese Betriebsart. Da funktioniert's dann natürlich auch, weil eben das DSL-Modem nicht am Layer-3-Traffic beteiligt ist.)

Oder Deinen Rechner mal als exposed host einzutragen (natürlich nur testweise). Und dann z.B. mit ethereal mal schauen.

Wie gesagt: Wenn ich eine Portweiterleitung (FBF-Jergon "Portfreigabe") für UDP-500 auf einen internen IPSec-Client aktiviere, dann kann ich IPSec-Tunnel aufbauen.
Die Exposed-Host-Funktion ist ja dann nur noch eine Portweiterleitung aller Ports, das brauche ich nicht - würde natürlich auch gehen.

Bzgl. Tunneln:

So in etwa. Ich kann da zwischen UDP und TCP wählen und dann werden alle IPSec-Pakete nochmal eingepackt, in normalen "IP" Paketen übers Netz geschickt und vom VPN-Server wieder ausgepackt. Hört sich überflüssig an, aber hat mir schon öfter unterwegs geholfen.

Überflüssig nicht, nur hochgradig proprietär und herstellerabhängig, vermutlich noch patent-abgeschirmt, und damit (für mich) quasi unbrauchbar. Für Spezialanwendungen und Einzelfälle natürlich nutz- und brauchbar.


Gruß, Harald

 

[telchef]

Ja, auch noch mal hallo!

[...]
Das verstehe ich allerdings nicht unter funktionierendem IPSec Pass-Through.

Ja, unter funktionierendem IPSec-Pass-Through verstehe ich auch was völlig anderes, als was AVM uns da bietet.
(Allerdings habe ich noch nirgends schriftlich direkt von AVM gesehen, daß das gehen können soll.)

In einem anderen Thread las ich jetzt noch, daß es auch mit ssh-Verbindungen Probleme gibt (selbstherrliches Entfernen der NAT-Verknüpfung nach ca. 10 Minuten Inaktivität, vermutlich ein Zugeständnis an das typische Einsatzszenario bei der surfenden DAU-Hausfrau)...

Heißt also: Bei AVM mal gezielt nachhaken was IKE angeht.

Ich arbeite dran.

EDIT: Ich habe nach einem Vorschlag die ausgehenden Pakete der Fritz gecaptured und geschaut, was das Portforwarding macht. Ergebnis: Es kann eigentlich nicht sein, dass der Client mit Portforwarding von Port 500 geht und ohne nicht, da es keinen Unterschied in der ausgehenden Verbindung gibt. In beiden Fällen findet kein Pass-Through statt, sondern Source Port 500 wird auf einen anderen umgesetzt.

Dafür weiß ich jetzt, dass ich gar nix mehr weiß ...

Ich muß mir das ganze auch nochmal ganz genau anschauen.
Vor allem weiß ich aber eines: Alle wertigen Router, die ich bisher kannte, konnten IPSec-Tunnel problemlos passieren lassen. Auch wenn dazu manchmal NAT-T nötig war.


Gruß, Harald

 

[telchef]

Hallo Volker!

Nach Traffic-Analyse kann ich folgendes sehen: Meine Testgegenstelle ist ein IPSec-Server, der IKE mit Source-Port != 500 nicht (korrekt) beantwortet.
(Auch minderwertig, denn auch in den alten IKE-v1-RFCs ist das nicht verlangt.)

Die FBF funkt diesen Server ohne aktivierte Portweiterleitung tatsächlich mit Source-Ports != 500 an, was ich nun also auch für richtig halte. (Hier habe ich AVM also teilweise zu voreilig beschimpft.)

Irgendwie war mir das gar nicht als Problemmöglichkeit bewußt, ich hatte nur ESP als schwieriges Protokoll in Erinnerung, welches man mit NAT-T bekämpfen kann. Daß manche IPSec-Gateways für Source-Ports unempfänglich sind, liegt ja auch nicht so nahe.

(Im [eigentlich was anderes beschreibenden] RFC 3104 wird übrigens nebenbei mal ausdrücklich darauf hingewiesen, daß in den RFCs 2407-2409 [zu IKE v1] der Source-Port gar nicht zwingend vorgeschrieben ist:
"IKE packets are typically carried on UDP port 500 for both source and destination, although the use of ephemeral source ports is not precluded [ISAKMP]. IKE implementations for use with RSIP SHOULD employ ephemeral ports, and should handle them as follows [IPSEC- MSG]: IKE implementations MUST support UDP port 500 for both source and destination, but other port numbers are also allowed.")

Allerdings bleibt zu klären, warum andere Router das trotzdem durchleiten können - und auch mit mehreren Clients aus ihrem eigenen geNATeten LAN. Ich werde das noch untersuchen.

Deine Anregung zum Source-Port und auch der Hinweis zu dem http://www.ip-phone-forum.de/showthread.php?t=92401 hat mich die Sache schnell finden lassen. Danke dafür!


Gruß, Harald