PPTP Server auf der Fritzbox funktioniert

[Blackbird1234]

Also ich habe es jetzt noch einmal getestet.


LOG PPTP Server:

[IP-Router] 2007/07/10 13:43:49,950
IP-Router Rx (LAN):
DstIP: 80.88.20.173, SrcIP: 80.237.199.1, Len: 1315, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: BLACKBIRD

Peer ist in dem fall die FritzBox

Fritz BOX:

- iptables nicht eingeschaltet

route:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
10.134.20.254 * 255.255.255.255 UH 0 0 0 dsl
10.134.20.254 * 255.255.255.255 UH 0 0 0 ppp0
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 0 0 0 ppp0

ifconfig ppp0:

ppp0 Link encapoint-to-Point Protocol
inet addr:80.88.20.173 P-t-P:10.134.20.254 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1000 Metric:1
RX packets:6544 errors:0 dropped:0 overruns:0 frame:0
TX packets:77215 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1661040 (1.5 MiB) TX bytes:24194644 (23.0 MiB)

Ping von aussen:

PING 80.88.20.173 (80.88.20.173) 56(84) bytes of data.
64 bytes from 80.88.20.173: icmp_seq=1 ttl=56 time=52.3 ms

tcpump:

tcpdump -i ppp0 -vv -l > dat -n udp & tail -f dat

Wenn ich von drinnen nach draussen telefoniere, sehe ich alles im dump, bei der Anmeldung beim SIP-Provider genauso. Aber wenn ich hineintelefoniere funktioniert es nicht.

Ich habe es auch getestet, indem ich das Kontrukt mit meinem PC nachgebaut habe. D.h. die Fbox durch einen PC ersetzt habe. Die Windows PPTP Einwahl gemacht habe und dann per Smartphone telefoniert habe. Da hat auch alles funktioniert. Also denke ich, das es irgendwo an der FBox liegt und alles vorher in Ordnung ist.

 

[RalfFriedl]

Schau Dir nochmal die Pakete an, mit denen sich der voipd beim SIP-Provider registriert. Laß bei tcpdump die OPtion -vv weg, die bringt hier nichts und macht nur die Ausgabe unübersichtlicher. Nimm statt dessen -X -s1500, um den Paketinhalt anzuzeigen.
Irgendwo in diesen Paketen muß die eigene IP-Adresse enthalten sein. Überprüfe mal, ob das die richtige Adresse ist, in Deinem Fall also die von ppp0 und nicht von dsl

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.134.20.254   *               255.255.255.255 UH    0      0        0 dsl
10.134.20.254   *               255.255.255.255 UH    0      0        0 ppp0

Diese Route ist bei Dir doppelt, ich weiß aber nicht, ob das eine Bedeutung hat oder nicht. (Für so eine Ausgabe verwendest Du am Besten die CODE-Tags oder das Symbol # in erweiterten Editor, damit bleibt die Formatierung der Tabelle erhalten.)

 

[Blackbird1234]

Irgendwo in diesen Paketen muß die eigene IP-Adresse enthalten sein. Überprüfe mal, ob das die richtige Adresse ist, in Deinem Fall also die von ppp0 und nicht von dsl

Ja, die Anmeldung erfolgt mit der 80er IP.Ein Anruf an den Voip Account kommt ja auch, laut PPTP Server Log auf die richtige IP zurück . Aber egal, ob ich udp oder tcp im tcpdump mitlaufen lasse, kommt der Call nicht auf die FBox. Was ich noch nicht getestet habe ist ein tcpdump auf einem anderen Interface als dem ppp0. Bzw. die Fbox noch einmal durch einen PC mit Linux zu ersetzen, wo ich dann die Einwahl per PPTP mache.

                       forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                                       "udp 0.0.0.0:7078 0.0.0.0:7078",
                                       "udp 0.0.0.0:7079 0.0.0.0:7079",
                                       "udp 0.0.0.0:7080 0.0.0.0:7080",
                                       "udp 0.0.0.0:7081 0.0.0.0:7081",
                                       "udp 0.0.0.0:7082 0.0.0.0:7082",
                                               .....
                        shaper = "globalshaper";

Was mich ja noch etwas irritiert sind Einträge in der ar7.cfg Das sind ja forward roules. Aber ich verstehe das any to any nicht so recht... könnte das vielleicht bei mir fehlen?

Diese Route ist bei Dir doppelt, ich weiß aber nicht, ob das eine Bedeutung hat oder nicht. (Für so eine Ausgabe verwendest Du am Besten die CODE-Tags oder das Symbol # in erweiterten Editor, damit bleibt die Formatierung der Tabelle erhalten.)

ja, die beim dsl muss ich setzen, um die defaultroute umzubiegen auf mein ppp0. Und das zweite kommt von ppp0. Macht aber keinen Unterschied, wenn ich die ppp0 Route wegnehme passiert leider auch nichts anderes.


THX Blackbird

 

[RalfFriedl]

Da kannst tcpdump auch mit der Option -iany aufrufen:

tcpdump -ns1500 -iany -X port not 22 and not 23

any bedeutet jedes Interface, und Port 22 und 23 werden ausgefiltert, weil sonst alle SSH und Telnet Pakete mit angezeigt würden, und das wäre schlecht, wenn man selbst per SSH oder Telnet mit der Box verbunden ist.
Wenn möglich läßt Du auch ein tcpdump auf dem PPTP-Server laufen, während ein Anruf hereinkommt.

Wenn bei einem eingehenden Anruf nichts an der Box ankommt, kann der Fehler nur an der Gegenstelle oder an den Registrierungsdaten liegen.

 

[Blackbird1234]

tcpdump -ns1500 -iany -X port not 22 and not 23

any

ahh danke, wieder was dazugelernt

Wenn möglich läßt Du auch ein tcpdump auf dem PPTP-Server laufen, während ein Anruf hereinkommt.

ok mach ich, tcpdump geht leider nicht, aber LCOS hat da auch ne Möglichkeit den IP-Router zu tracen.

Wenn bei einem eingehenden Anruf nichts an der Box ankommt, kann der Fehler nur an der Gegenstelle oder an den Registrierungsdaten liegen.

Ja die Befürchtung hatte ich auch, meine andere Sorge ist/war , das irgendeine Firewall, die vielleicht standartmäßig auf der fbox läuft die Ports blockt.

Komme leider erst am WE wieder dazu das auszuprobieren, aber danke erstmal und ich werde mich bei Erfolg oder Mißerfolg wieder melden

 

[Blackbird1234]

Also im Moment bin ich etwas am rätseln, vielleicht auch schon am verzweifeln .


Beim tcpdump kommt nix an, bei einem eingehenden Call. Also nochmal ein tcpdump auf dem PPTP-Server laufen lassen.

Ausgehender Call:

[IP-Router] 2007/07/14 15:12:48,240
IP-Router Rx (BLACKBIRD):
DstIP: 80.237.199.1, SrcIP: 80.88.20.175, Len: 391, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: 80.88.20.254, LAN Tx

[IP-Router] 2007/07/14 15:12:48,220
IP-Router Rx (LAN):
DstIP: 80.88.20.175, SrcIP: 80.237.199.1, Len: 472, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: BLACKBIRD

So das sieht erstmal ganz gut aus. Der Call geht über von der Fbox mit der IP 80.88.20.175 an den SIP Server mit der IP 80.237.199.1 . Funktioniert auch. Wenn ich jetzt einen Rückruf mache, sollte das genauso aussehen.

[IP-Router] 2007/07/14 15:15:09,860
IP-Router Rx (LAN):
DstIP: 80.88.20.175, SrcIP: 80.237.199.1, Len: 1315, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: BLACKBIRD

OK, damit sehe ich, das der Call reinkommt und auch zu meiner FBox weitergeleitet wird. Allerdings nimmt die FBOX "nichts an". Ich sehe nichts im tcpdump und ich sehe nichts im voipd.

Gleicher Test, ohne FBOX sondern mit einem PC an gleicher Stelle funktioniert alles. Daraus schließe ich, das es nicht am PPTP Server liegt.

Iptables sind nicht aktiviert.

/ $ iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ich komme definitiv mit der Fbox ins Internet. Des weiteren komme ich per telnet vom Internet auf die FBOX.

 telnet 80.88.20.175
Trying 80.88.20.175...
Connected to 80.88.20.175
Escape character is '^]'.

BusyBox v1.5.1 (2007-07-07 14:02:48 CEST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

Also ist die FBox von aussen erreichbar.

Log des Voipd beim anmelden

voipd: STUN: udp 5060 -> 80.88.20.175:5060
voipd: ip address changed 169.254.1.1:5060 -> 80.88.20.175:5060
voipd: XXX: my address 80.88.20.175:5060
voipd: [email protected]: REGISTER starting
voipd: [email protected]: REGISTER already in progress
voipd: >>>UDP Request: REGISTER sip:80.237.199.1 (1)
voipd: <<<UDP Status: 401 Unauthorized (1)
voipd: >>>UDP Request: REGISTER sip:80.237.199.1 (2)
voipd: <<<UDP Status: 200 OK (2)
voipd: >>>UDP Request: REGISTER sip:80.237.199.1 (3)
voipd: <<<UDP Status: 200 OK (3)
voipd: [email protected]: REGISTER end
voipd: [email protected]: REGISTER (sip:[email protected]
5;uniq=XXX) complete (next in 1620 seconds)
voipd: VoIP led value = 1
voipd: >>>UDP Request: SUBSCRIBE sip:[email protected] (4)
voipd: <<<UDP Status: 200 Ok (4)
voipd: SUBSCRIBED: message-summary sip:[email protected] 0.0

ein nmap von aussen auf die FBOX sagt folgendes.

PORT     STATE SERVICE
5060/tcp open  unknown
5060/udp open|filtered unknown
7077/udp open|filtered unknown

Da kommt mir ein wenig komisch vor. Da die UDP Ports auf open|filtered stehen. Es sind eigentlich keine Filter definiert.

Der nächste Test war ein telnet auf Port 5060 von extern. Und siehe da ich bekomme eine Verbindung zum Voipd auf TCP. Also könnte es vielleicht tatsächlich an den UDP Ports liegen?

Wer macht sie zu?


THX

 

[RalfFriedl]

Das open|filtered bei udp bedeutet nur, daß ein Portscan bei UDP schwieriger ist als bei TCP.
Bei TCP kommt immer eine Antwort, ob die Verbindung angenommen wird oder nicht, es sei denn, es ist ein Filter davor.
Bei UDP ist es üblich, eine Rückmeldung zuschicken, wenn der Port zu ist, aber nicht verpflichtend und nicht unbedingt auf jedes Paket.
Wenn der Port offen ist, hängt es von der Anwendung ab, ob auf ein Paket eine Antwort kommt. Wenn ja, ist klar, daß der Port offen ist. Wenn nicht, hat entweder eine Anwendung das Paket angenommen und ignoriert, oder ein Filter hat das Paket abgeblockt. Dasher die Anzeige open|filtered, weil nmap nicht zwischen den beiden Fällen unterscheiden kann. Das ist im Manual von nmap auch näher erläutert.

Wenn Dein PPTP-Server meint, daß er das SIP-Paket weiterleitet, es auf der Box aber nicht ankommt, muß es irgendwo dazwischen vorloren gehen.

Ist Dein tcpdump von PPTP Server auf dessen Verbindung zum Internet oder auf dessen Verbindung zu Dir?

Wenn Du tcpdump mit der Option -iany laufen läßt, müßtest Du auch die PPTP Pakete angezeigt bekommen. Hier siehst Du zwar keinen Inhalt, da der ja verschlüsselt ist, aber Du müßtest feststellen können, ob überhaupt etwas bei Dir ankommt bei einem eingehenden Anruf. dafür mußt Du natürlich sicherstellen, daß in dem Moment sonst nichts los ist auf der Leitung.

Versuch auch mal einen eingehenden Anruf möglichst schnell nachdem sich voidp registriert hat.

 

[Blackbird1234]

Also, es scheint am PPTPClient zu liegen. Ich habe das gleiche Szenario jetzt mal mit nem Linux PPTP Client auf einem PC an der Stelle der FBox getestet und es hat nicht funktioniert. Ohne PPTP, d.h. mit DHCP IP Adresse funktioniert es. Also werd ich mal weitersuchen... :/

EDIT:So, Problem gelöst... nach Stundenlangem suchen, hab ich den Fehler in meinem PPTP Client gefunden. Es war einfach in den Options eine falsche MTU/MRU eingetragen. Nachdem ich das einfach rausgenommen habe funktioniert es wunderbar. D.h. Ausgehender Call, Reinkommender Call, PC's hinter der Fbox und Portweiterleitung nach drinnen. Jetzt nur noch ein CGI schreiben und dann wars das glaube ich schon..

Danke an RalfFriedl , das mit den PPTP Paketen war eine gute Idee .

 

[eddy039]

nicht konfigurierbar?

Hallo!

Nachdem ich nun seit Monaten den pptpd erfolgreich mit der .25er 7170 Firmware
eingesetzt hatte, hab ich mir nun mal mit der .37 und ds26-15.1 ein neues
Image gebaut. Nun kann ich im Webinterface den pptpd nicht konfigurieren,
bei options_pptpd und pptpd_conf wird mir der Inhalt der vorgegeben
Standard-Konfig angezeigt und kann nicht editiert werden.

Oben drüber erscheint der Schriftzug:

Konfiguration in der aktuellen Sicherheitsstufe nicht verfübar!

Hat jemand einen Tip, was da schief läuft?

Gruß, ed

 

[kriegaex]

Suchfunktion mit der Meldung benutzen. ;-)

 

[eddy039]

Jepp, sorry...wollt gerade editieren, das es sich erledigt hat...

 

[cuma]

Hallo Forum

Ich versuche, leider erfolglos pptp auf meiner 7170 zum laufen zu bringen. Dabei bin ich nach dem Wiki vorgegangen:

1) Der Patch "linux-2.6.13-mppe-mppc-1.3_DS-MOD.patch": braucht man diesen noch im aktuellen ds25-1.2 zusätzlich? So eine Datei existiert schon in /make/linux/patches/. Ich habe den Patch mal weggelassen und mal nicht

2) "make kernel-menuconfig" brauche ich dies 2 Crypro und 5 ppp Module statisch? Im "make menuconfig" kann ich diese auch modular bauen lassen. Dies sollte doch ausreichen, solange diese geladen sind

3) Addon "pptpd-1.3.3": Installation kein Problem und lässt sich über die :81 Weboberfläche konfigurieren, was ich auch getan habe.

4) "libgcc_s.so.1" und "libutil-0.9.26.so" sind sowieso per Default ausgewählt

Soweit alles kein Problem, der pptp startet auch:

pptpd[3886]: MGR: Maximum of 8 connections available<000>
pptpd[3886]: MGR: Manager process started<000>
pptpd[3884]: MGR: Maximum of 100 connections reduced to 8, not enough IP addresses given<000>

Nur bei Verbindungsversuchen eines WinXP Clients bekomme ich immer:

pptpd[4009]: CTRL: Client 192.168.1.6 control connection finished<000>
pptpd[4009]: CTRL: Reaping child PPP[4010]<000>
pptpd[4009]: CTRL: PTY read or GRE write failed (pty,gre)=(7,8)<000>
pptpd[4009]: GRE: read(fd=7,buffer=45174c,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs<000>
pppd[4010]: This system lacks kernel support for PPP. This could be because<010>the PPP kernel module could not be loaded, or because PPP was not<010>included in the kernel configuration. If PPP was included as a<010>module, try `/sbin/modprobe
pptpd[4009]: CTRL: Starting call (launching pppd, opening GRE)<000>
pptpd[4009]: CTRL: Client 192.168.1.6 control connection started<000>

Seltsam ist, dass die Crypto sowie die ppp Module mit "modprobe" ohne Fehler geladen werden können, aber anschliessend in "lsmod" nicht auftauchen

Was habe ich übersehen? Ich habe das ganze mit der Labor-FON als auch der "normalen" Firmware ausprobiert.

 

[kriegaex]

Siehst Du auf der Konsole irgendeine Antwort, wenn Du modprobe machst? Falls ja, welche?

 

[RalfFriedl]

Seltsam ist, dass die Crypto sowie die ppp Module mit "modprobe" ohne Fehler geladen werden können, aber anschliessend in "lsmod" nicht auftauchen.

Wenn sie bei lsmod nicht auftauchen, sind sie auch nicht geladen.
Was genau heißt "ohne Fehler"?
Kommt bei modprobe keine Meldung, oder erscheint etwas mit Success hinten?

Das Kommando dmesg zeigt Dir die Kernel-Meldungen an, vielleicht steht dort etwas hilfreiches.

 

[wonderdoc]

Ich hatte mir den pptpd auch mal zum testen installiert gehabt.
Allerdings mit dem ds26-15.
Unter "kernel-menuconfig" hatte ich die crypto und PPP Module auch modular bauen lassen.(wie def. von oli eingestellt)
Unter "make menuconfig" hatte ich das pppd-package auch ausgewählt, somit wurde auch die benötigten Module aktiviert.
Wichtig bei der Sache ist natürlich die Option "Replace kernel", da bei org. Kernel ja die Module sonst fehlen.
Hatte daher daß ganze mit der std-Firmware 29.04.33 getestet gehabt.
Da das pptpd-Addon aber nicht von modular gebauten Modulen ausgeht, mußte ich die rc.pptpd noch anpassen.
Wichtig war, daß die Module in einer bestimmten Reihenfolge geladen werden.

# addon\pptpd-1.3.3\root\etc\init.d\rc.pptpd

start() {
	if [ -r "/tmp/flash/chap-secrets" ]; then
		cp /tmp/flash/chap-secrets /var/flash
	else
		cp /etc/default.pptpd/chap-secrets /tmp/flash
		cp /tmp/flash/chap-secrets /var/flash
	fi

	if [ -r "/tmp/flash/options.pptpd" ]; then
		cp /tmp/flash/options.pptpd /var/flash
	else
		cp /etc/default.pptpd/options.pptpd /tmp/flash
		cp /tmp/flash/options.pptpd /var/flash
	fi

	if [ -r "/tmp/flash/pptpd.conf" ]; then
		cp /tmp/flash/pptpd.conf /var/flash
	else
		cp /etc/default.pptpd/pptpd.conf /tmp/flash
		cp /tmp/flash/pptpd.conf /var/flash
	fi

	echo -n 'Starting pptpd...'
	modprobe arc4
	modprobe sha1
	modprobe ppp_async
	modprobe ppp_deflate
	modprobe ppp_generic
	modprobe ppp_mppe_mppc
	$DAEMON -c /var/flash/pptpd.conf
	exitval=$?
	if [ "$exitval" -eq 0 ]; then
		echo 'done.'
	else
		echo 'failed.'
		exit $exitval
	fi
}

stop() {
	echo -n 'Stopping pptpd...'
	killall $DAEMON > /dev/null 2>&1
	exitval=$?
  rmmod ppp_async
	rmmod ppp_generic
	rmmod ppp_deflate
	rmmod ppp_mppe_mppc
	rmmod arc4
	rmmod sha1
	rm -f /var/flash/chap-secrets
	rm -f /var/flash/options.pptpd
	rm -f /var/flash/pptpd.conf

	if [ "$exitval" -eq 0 ]; then
		echo 'done.'
	else
		echo 'failed.'
		exit $exitval
	fi
}
...

Ich habe mich danach zumindest von meinem Win-Rechner per ppp auf die FB connecten können,
habe dann die Sache erstmal nicht weiter testen können.(Routing und co)

mfg
Wonderdoc

 

[cuma]

zu modprobe: Es erscheint keinerlei Meldung auf dem Terminal, bei "dmesg" noch per Syslog.
Normalerweise benutze ich die Labor-FON. Ist das Laden der Module hier nicht möglich? Das "replace kernel" wird ja nur bei der normalen Firmware angeboten.
Ich benutze allerdings noch andere Module mit dem Labor-FON, zB "ftdi_sio" welches ich ja auch genau so ausgewählt und erstellt habe. Dieses kann trotzdem problemlos laden werden!

@Wonderdoc: Ich habe das Skript bei mir mal angepasst, hat aber auch nicht geholfen. Allerdings habe ich die Reihenfolge noch verändert, da die 3 ppp* Module von ppp_generic abhängen

 

[kriegaex]

Keine Meldung ist gut. Die Ausgabe bei Fehlern ist buggy und schreibt immer sowas wie "success" auf die Konsole, was völliger Blödsinn ist und gern mal als Erfolg interpretiert wird (kein Wunder, ging mir anfangs auch so). Aber so, wie Du es beschreibst, sollten die Module geladen werden. Seltsam.

 

[cuma]

So, bin jetzt weiter gekommen.

Zuerstmal die Reihenfolge der Module bei mir in rc.pptp:

modprobe slhc
modprobe sha1
modprobe arc4	
modprobe ppp_generic
modprobe ppp_deflate
modprobe ppp_async
modprobe ppp_mppe_mppc

Wenn ich die Module über Dropbear laden will erscheinen keinerlei Meldungen. Beim Laden in der rc.pptp klappt es allerdings! Dann werden auch über "lsmod" die (erfolgreichen) Module angezeigt.
Leider schlagen arc4,sha1 und ppp_mppe_mppc fehl:

kernel: ppp_mppe_mppc: Unknown symbol crypto_alg_available<000>
kernel: ppp_mppe_mppc: Unknown symbol crypto_free_tfm<000>
kernel: ppp_mppe_mppc: Unknown symbol crypto_alloc_tfm<000>
kernel: PPP Deflate Compression module registered<000>
kernel: PPP generic driver version 2.4.2<000>
kernel: arc4: Unknown symbol crypto_unregister_alg<000>
kernel: arc4: Unknown symbol crypto_register_alg<000>
kernel: sha1: Unknown symbol crypto_unregister_alg<000>
kernel: sha1: Unknown symbol crypto_register_alg<000>
kernel: CSLIP: code copyright 1989 Regents of the University of California<000>

Es fehlt also wohl ein "cypto" Modul. Nur welches?

 

[RalfFriedl]

Du brauchst aus der Kernel-Config "Cryptographic options"/"Cryptographic API".
Wenn es im Kernel fest ist, muß Du den Kernel ersetzen.
Wenn es als Modul erstellt wird, muß Du das Modul vorher laden.

 

[cuma]

Danke für die schnelle Antwort!
Also ich habe "make kernel-menuconfig" nicht benutzt zum erstellen der Firmware. Habe mir das ganze aber mal genau angeschaut: Wenn man "sha1" oder "arc4" dort auswählen will, muss man vorher "Cryptographic API" auswählen.
Im dsmod "make menuconfig" können unter Advanced options>Kernel modules>crypto nur die 2 besagten Module zum Einbinden auswählt werden. Deshalb muss dann ja wohl auch die "Cryptographic API" aktiviert sein?!
Wie kann ich denn herausfinden ob diese verfügbar ist bzw wie kann ich diese laden?