PPTPD: VPN-Verbindung steht, Client und Server können sich aber nicht pingen

[udosw]

Sorry, dass ich noch einen Thread zum PPTP-Daemon aufmache, aber in dieser Form habe ich das Problem in den anderen Posts nicht gefunden.

Ich habe das Paket PPTPD (mit Kernel replace) auf meiner 7270, Labor AiO, freetz-devel, zum Laufen gebracht.

Meine Clients (Sowohl Win XP Bordmittel als auch E71 SymVPN) connecten erfolgreich und bekommen eine IP (192.168.178.171) zugewiesen. Die Verbindung bleibt auch dauerhaft stehen. Aber ich kann die IPs von Client und Server gegenseitig nicht pingen. (Die Box ist auf 192.168.178.1).

Wenn die Verbindung steht, habe ich auf der Box:

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:192.168.178.1  P-t-P:192.168.178.171  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1400  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:138 (138.0 B)  TX bytes:336 (336.0 B)

Ich habe mit http://192.168.178.1/cgi-bin/webcm?getpage=../html/capture.html packete gecaptured und kann auch die PPTP-Verbindung sehen.

Aber mir ist nicht klar, wie ich die Pings verfolgen kann, von welchem Interface muss ich überhaupt ausgehen. Hat da jemand mal einen Tipp? (Die Debug-Anleitung auf der POPTOP-Seite habe ich gelesen, aber die geht davon aus, dass wenigstens dieser Ping klappt).

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.178.202 0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.178.171 0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.178.201 0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
77.21.32.0      0.0.0.0         255.255.252.0   U     2      0        0 dsl
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

Oder geht der PPTPD z.Zt. auf der 7270 gar nicht richtig, und ich kann lange suchen?

Udo

PS: Mit nahezu denselben Einstellungen betreibe ich einen PPTDP-Server (POPTOP) unter Debian-Linux, mit dem die VPN-Verbindungen (von denselben Clients) problemlos funktionieren. Das könnte ja zum Debuggen nützlich sein.

 

[TheBadFish]

pptpd sowie pptp machen auf der 7270 grad Probleme. Ich krieg pptp auch nicht ans laufen, sieher hier: http://www.ip-phone-forum.de/showthread.php?t=192328&page=3


Zum Thema Paketverfolgung: Nimm tcpdump. Kommandozeilenoptionen siehe Link in der Wikipedia.

 

[udosw]

http://www.ip-phone-forum.de/showthread.php?t=192328&page=3

Ja, aber das ist eben anders. Dort kommt die PPTP-Verbindung ja gar nicht zu Stande bzw. bricht gleich wieder ab.

Meine Verbindung steht ja stabil (der Trick war übrigens mppe statefull in das Configfile aufzunhmen), nur das Routing geht nicht.

Aber ich habe gerade etwas gesehen in den Dumps:

Internet Protocol, Src: 77.25.XXX.XX, Dst: 169.254.2.1 (169.254.2.1)

Der PPTPD scheint auf 169.254.2.1 zu lauschen, nicht auf 192.168.178.1 !!!

Das bedeutet, dass ich vielleicht nur eine route setzen muss ...
Leider habe ich mich vorhin durch löschen einer solchen ausgesperrt. Ich muss wohl heute früher nach hause .

Udo

 

[cuma]

Also bei mir kommt die Verbindung zustande und bricht auch nicht gleich ab. Es können aber keine Daten übertragen werden

 

[TheBadFish]

Dito beim mir am pptp Client. Sieht alles toll aus, aber es geht nix.

 

[udosw]

Der PPTPD scheint auf 169.254.2.1 zu lauschen, nicht auf 192.168.178.1 !!!

Leider auch kein Erfolg. Es scheint so, als ob überhaupt keine IP-Pakete über die PPTP-Verbindung gehen. tcpdump zeigt mir jedenfalls nichts an (ich weiß, wie man es bedient).

Wenn jemand weitere Tipps zum Debuggen hat, immer her damit.

Udo

 

[TheBadFish]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Kann leider nicht weiter testen, meine 7270 ist übern Jordan dank eines Blitzeinschlags im Garten.

Werde hier aber trotzdem weiter beobachten. Falls jemand ne Lösung findet kann ich evtl wieder alles auf einer Box machen und die 7141 verschwindet wieder im Schrank.

[Beitrag 2:]
Nur eine Vermutung, aber hast du die Möglichkeit deine 7270 mal als reinen IP Client zu schalten?

Irgendwo scheint ja das Routing nicht zu funktionieren und das würde in der Routingtabelle ziemlich Rambazamba machen.

 

[markuschen]

Also ich habe keine Probleme mit meinem PPTPD, ich verbinde mich aber ausschließlich mit Windows-PC's zum PPTPD meiner Fritz.Box 7270. Vlt. nützt es jemandem, ich hänge mal meine Server-Config's an.

options.pptpd:

name fritzbox
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
mtu 1400
mru 1400
proxyarp
lock

pptpd.conf:

ppp /usr/sbin/pppd
option /var/tmp/flash/ppp/options.pptpd
#bcrelay lan
localip 192.168.178.1
remoteip 192.168.178.199

BTW: Iht müsst auf der 7270 den bcrelay unbedingt ausschalten, siehe hier.

 

[cuma]

Auch mit deiner Konfig klappt es bei mir nicht. Hab noch zufällig diese Meldung per Syslog aufgeschnappt:

ppp: compressor dropped pkt

http://marc.info/?l=pptpclient-devel&m=112083190420391&w=2

> + } else {
> + /*
> + * (len < 0)
> + * MPPE requires that we do not send unencrypted
> + * frames. The compressor will return -1 if we
> + * should drop the frame. We cannot simply test
> + * the compress_proto because MPPE and MPPC share
> + * the same number.
> + */
> + if (net_ratelimit())
> + printk(KERN_ERR "ppp: compressor dropped pkt\n");

 

[cuma]

Hat mittlerweile jemand Neuigkeiten?
Bei Tests bekam ich noch viele der folgenden Meldung

kernel: extract_dst: saddr mismatch <externe IP der Fritzbox> != <verschiedene IPs>

Die verschiedenen IPs waren solche, die am vpn-Client im Browser offen waren. DHCP funktioniert übrigens

EDIT:
Hab es jetzt halbwegs am laufen. Eine Verbindung ist möglich, wenn man das "mppe required" herausnimmt. Allerdings wird dann nicht mehr verschlüsselt und erfüllt somit seinen Sinn nichtmehr so ganz...
Wie es aussieht also wieder ein Problem mit dem Kernel und den crypto-libs. Langsam nervt mich das ganze wirklich -.-
Mit einer älteren Firmware und der gleichen Konfiguartion funktionierte es jedenfalls mal

 

[hermann72pb]

Naja, wie es aussieht, sollte sich irgendein Hacker mit Erfahrung unter uns die OpenSSL-Geschichte ernst anschauen und versuchen AVM-Konfiguration zu "erraten". Zielsetzung wäre entweder FREETZ-eigene-OpenSSL AVM-konform zu erstellen (was wahrscheinlich nicht gelingt), oder AVM-OpenSSL für FREETZ-eigene SSL-Sachen zu verwenden. Interessant wäre eine Möglichkeit zu finden OpenSSL zu splitten, dass man die Sachen, die AVM evtl. nicht drin hat in einer Unterbibliothek auslagert. Wenn AVM die Configs und Sourcen für OpenSSL nicht ausrücken will, dann wird mal wohl "reverse engineering" betreiben müssen.

MfG

 

[cuma]

Mit dem Raten ist das so ne Sache, bestimmt hat AVM da noch was reingebastelt. Ich sehe da 2 Möglichkeiten
1) LD_LIBRARY_PATH für eigene Programme
2) AVM verklagen

 

[hermann72pb]

Verklagen kannst du vergessen. OpenSSL hat eine andere Lizenz, als z.B. Kernel und busybox. AVM sind da gesetzlich sauber (vom moralischen lass uns lieber schweigen), wenn sie nichts publik geben. Ich hatte schon diesbezüglich eine Korrespondenz mit AVM geführt.
Deine Idee 1 ist auch nicht schlecht, allerdings besser wäre es nicht alles doppelt und dreifach zu haben, sondern versuchen irgendwie gemeinsame Resourcen zu nutzen. Ich weiß, dass es von sehr schwer bis quasi unmöglich ist, aber vielleicht schafft es jemand.

MfG

 

[cuma]

Sowas hatte ich schonmal gelesen. Also den AVM-Teil lassen wie er ist und in den rc-Skripten der betroffenen Programme auf eine eigene Kompilierungen umleiten

 

[olistudent]

Ich denke das ist die einzige machbare Möglichkeit die wir haben...

MfG Oliver

 

[meiser79]

Hi,

könnte jemand nochmal mit aktuellem freetz-trunk testen? Es gab da wohl Probleme mit manchen PPTP Clients.
Ich hab dafür einen Fix (http://www.freetz.org/changeset/3563) eingecheckt.

Danke,
Whoopie

 

[cuma]

Damit werden bei mir keine Daten übertragen, wenn die Datenverbindung verschlüsselt ist :-(

 

[udosw]

könnte jemand nochmal mit aktuellem freetz-trunk testen?

Danke für's einchecken, aber ich kann den PPTPD gar nicht ins Paket aufnehmen (wird nicht angeboten). Liegt das daran, dass 'replace kernel' z.Zt. bei er 7270 nicht geht?
Udo

 

[cuma]

Richtig. Im Trunk gehts allerdings

 

[olistudent]

Hab ich das gestern vergessen zu mergen? Eigentlich sollte replace kernel mit der 7270 gehen.

MfG Oliver