FB7270 und pptp -> Patch einspielen

[TheBadFish]

Also, sämtliche Tests die ich im Moment mache gehen von der Fritzbox aus, d.h. ich hänge per telnet auf der Fritzbox. Die ganze Pingerei versuche ich im Moment von der Fritzbox aus. Und da geht nichts an den Server (.142) raus. Die internen Clients, also meine Rechner hier im Subnetz 179.0 sind noch gar nicht mit von der Partie.

Ja, deine Erläuterung leuchtet mir ein. Ich habe hier eine LAN-2-LAN Kopplung. Mein Rechner spielt zwar Client, muss aber das Subnetz an mein internes Netz durchrouten. Sonst komm ich natürlich später mit meinen internen Clients nicht übers VPN raus, das ist soweit schon klar.

Und um auch nochmal zu verdeutlichen wo ich im Moment stehe:

Früher war das so:

Win-VPN-Server <==> Win-Client | womit ich eine Client2Lan Verbindung hatte. Ich konnte das komplette entfernte Netz mit all seinen Diensten erreichen.

Jetzt will ich:

Win-VPN-Server <==> pptp auf FBF <--Routing-ins-interne-Netz--> InterneClients

 

[stinkstiefel]

Also, sämtliche Tests die ich im Moment mache gehen von der Fritzbox aus, d.h. ich hänge per telnet auf der Fritzbox. Die ganze Pingerei versuche ich im Moment von der Fritzbox aus.

Das war ja wenigstens mal eine klare Ansage. Wir drehen uns trotzdem langsam im Kreis. Ohne zu wissen das wirklich nichts aus der Fritz!Box raus geht oder aber etwas beim Server ankommt und nur nicht wieder bei der Fritz!Box landet gehts hier nicht weiter.

 

[TheBadFish]

Richtig, ich meld mich wieder wenn das geklärt ist.

 

[TheBadFish]

Also, es kommen auf Seite des Servers keine Pakete an. Ich kapiers einfach nicht. Die Verbindung steht einwandfrei, aber es geht nichts durch.

/Edit: Ich hab mal noch etwas weitergeforscht. Der Befehl "route" spuckt folgendes aus:

/var/mod/root # route
Kernel IP routing table
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
87.178.***.***  *               255.255.255.255 UH    2      0        0 dsl
192.168.178.142 *               255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   192.168.178.142 255.255.255.0   UG    0      0        0 ppp0
192.168.179.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     2      0        0 dsl

Was macht die Zeile 192.168.178.142 da, und was ist das für ne Subnetmaske?
Die Zeile mit 178.0 verschwindet wenn ich das Routing im Freetz Webinterface deaktiviere.


/Edit2: Als ich damals mit dem VPN Client von AVM rumgespielt habe trat folgendes auf, eventuell liegt da der Hund begraben. Mein lokales Netz war 179.0. Das entfernte Netz zu dem ich verbinden wollte war ...178.0. Damals hat mich das Tool von AVM angemeckert, dass das nicht geht, das entfernte Netz darf nicht im Adressbereich 178 liegen. Ich versteh zwar nicht warum das nicht gehen soll, aber die Software hat sich geweigert.
Könnte das ein allgemeines Problem der Fritzbox sein, dass VPN nicht tut wenn eines der Netze 178.0 ist?

 

[stinkstiefel]

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.178.142 *               255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   192.168.178.142 255.255.255.0   UG    0      0        0 ppp0

Was macht die Zeile 192.168.178.142 da, und was ist das für ne Subnetmaske?

Welche meinst du denn?

192.168.178.0   192.168.178.142 255.255.255.0   UG    0      0        0 ppp0

Diesen Eintrag löschen und route add -net 192.168.178.0 netmask 255.255.255.0 dev ppp0 verwenden.

 

[TheBadFish]

Womit das Routing jetzt so aussieht:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
87.178.***.***  *               255.255.255.255 UH    2      0        0 dsl
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
192.168.178.142 *               255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   *               255.255.255.0   U     0      0        0 ppp0
192.168.179.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     2      0        0 dsl

auch das hat leider nichts gebracht.

Ich würde den Tunnel ja auch über IPSEC mit Zertifikaten aufbauen, aber ich finde kein Paket dass das unterstützt, vpnc kann es nicht.

 

[stinkstiefel]

Jetzt passt aber default noch nicht.

default         *               0.0.0.0         U     2      0        0 dsl

Sollte wie folgt aussehen

default   87.178.***.*** 0.0.0.0   UG    0      0        0 dsl

 

[TheBadFish]

Ich hab mich jetzt mal ein bisschen in die Funktion der Routingtabelle eingelesen....

Hier mal die bereinigte Routingtabelle von oben durchnummeriert:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1   87.178.***.***  *               255.255.255.255 UH    2      0        0 dsl
2   192.168.178.142 *               255.255.255.255 UH    0      0        0 ppp0
3   192.168.178.0   *               255.255.255.0   U     0      0        0 ppp0
4   192.168.179.0   *               255.255.255.0   U     0      0        0 lan
5   default         *               0.0.0.0         U     2      0        0 dsl

-Warum brauche ich Route 2? Route 3 impliziert diese doch?
-Und was ändert sich wenn ich ein Gateway in die Default Route reinsetze?


Wenn ich die default route lösche und sie mit

route add -net 0.0.0.0 netmask 0.0.0.0 gw 87.178.***.*** dev dsl

neu anlegen will, bekomme ich ein "route: SIOCADDRT: Network is unreachable".

 

[stinkstiefel]

Um default musst du dich eigentlich überhaupt nicht kümmern. Die wird eigentlich beim herstellen der Internetverbindung automagisch eingerichtet. Wenn das bei dir nicht funktioniert such nach der Ursache.

 

[TheBadFish]

Versteh ich nicht. Du sagtest doch ich muss sie ändern? Wie soll ich das machen, wenn nicht löschen und neu erstellen?

Ich steck da nicht ganz so tief drin, wie du vielleicht schon festgestellt hast.

 

[stinkstiefel]

Wenn es jetzt noch so ausschaut wie zuletzt dann zunächst mal "route del default" danach die PPTP Verbindung und die Internetverbindung trennen. route -n anschauen eventuell herzeigen. Als nächstes dann Internetverbindung herstellen und route -n anschauen eventuell herzeigen. Weiterer Schritt PPTP Verbindung herstellen route -n ansehen eventuell herzeigen.

 

[TheBadFish]

So. Ausgangssituation:

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
87.178.***.***  0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.178.142 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   192.168.178.142 255.255.255.0   UG    0      0        0 ppp0
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
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

Jetzt ein route del default, pptp und Inet getrennt, in dieser Reihenfolge endet hier:

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
87.178.***.***   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan

Jetzt DSL Verbindung wieder aufgebaut:

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
87.178.***.*** 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.179.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan

Versuch die PPTP Verbindung wieder aufzubauen schlägt fehl, Routing im Freetz/PPTP Webinterface aktiviert (192.168.178.0 255.255.255.0)
Auszug der syslog:

May 22 21:40:32 fritz daemon.info pppd[2486]: pppd options in effect:
May 22 21:40:32 fritz daemon.info pppd[2486]: debug             # (from command line)
May 22 21:40:32 fritz daemon.info pppd[2486]: nodetach          # (from command line)
May 22 21:40:32 fritz daemon.info pppd[2486]: logfd 2           # (from command line)
May 22 21:40:32 fritz daemon.info pppd[2486]: dump              # (from command line)
May 22 21:40:32 fritz daemon.info pppd[2486]: noauth            # (from /etc/ppp/options.pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: refuse-pap                # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: refuse-chap               # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: refuse-mschap             # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: refuse-eap                # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: name Skynet\\Cosmo                # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: remotename PPTP           # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]:           # (from /etc/ppp/options.pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: pty pptp maulwurf.homelinux.org --nolaunchpppd            # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: ipcp-accept-local         # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: ipcp-accept-remote                # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: ipparam pptp              # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: nobsdcomp         # (from /etc/ppp/options.pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: nodeflate         # (from /etc/ppp/options.pptp)
May 22 21:40:32 fritz daemon.info pppd[2486]: mppe xxx # [don't know how to print value]                # (from /etc/ppp/peers/pptp)
May 22 21:40:32 fritz daemon.notice pppd[2486]: pppd 2.4.4 started by root, uid 0
May 22 21:40:32 fritz daemon.debug pppd[2486]: using channel 6
May 22 21:40:32 fritz daemon.info pppd[2486]: Using interface ppp0
May 22 21:40:32 fritz daemon.notice pppd[2486]: Connect: ppp0 <--> /dev/pts/3
May 22 21:40:32 fritz daemon.notice pptp[2488]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
May 22 21:40:32 fritz daemon.warn pptp[2488]: anon warn[pptp_gre_bind:pptp_gre.c:100]: connect: Network is unreachable
May 22 21:40:32 fritz daemon.crit pptp[2488]: anon fatal[main:pptp.c:322]: Cannot bind GRE socket, aborting.
May 22 21:40:32 fritz daemon.debug pppd[2486]: Script pptp maulwurf.homelinux.org --nolaunchpppd finished (pid 2487), status = 0x1
May 22 21:40:32 fritz daemon.notice pppd[2486]: Modem hangup
May 22 21:40:32 fritz daemon.notice pppd[2486]: Connection terminated.
May 22 21:40:32 fritz daemon.info pppd[2486]: Exit.

Wenn ich jetzt versuche mit

route add -net default gw 87.178.***.*** dsl

die route zu legen schlägt dies immer noch fehl. (route: SIOCADDRT: Network is unreachable)

Wenn ich die alte route wieder lege, also ohne das Gateway kann ich die pptp Verbindung wieder aufbauen, was dann so aussieht:

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
87.178.***.*** 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.142 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   192.168.178.142 255.255.255.0   UG    0      0        0 ppp0
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
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     0      0        0 dsl

 

[stinkstiefel]

Nach dem herstellen der Internetverbindung fehlt die Defaultroute. Ausserdem irretiert mich das es Routen mit unterschiedlicher Metric gibt. Irgend was hast du da also vermutlich schon verändert und vielleicht auch kaputt gemacht. Ich habe keine Ahnung von freetz deswegen würde ich wohl jetzt komplett von vorne beginnen.

 

[TheBadFish]

Ich glaub ich setz das ganze wirklich mal neu auf. Also so richtig Vollgas, Recover und dann händisch die Einstellungen machen, nicht das alte exportfile wieder drüber laufen lassen.

Was sagt mir die "Metric"?

/Edit: Ich dank dir auf jeden Fall jetzt schonmal für die tatkräftige Unterstützung. Meld mich auf jeden Fall nochmal, entweder es funktioniert nach dem neu aufsetzen, oder ich nerv dich weiter. :mrgreen:

 

[cuma]

Metric ist dir Priorität/Kosten/Bandbreite der Route. Braucht du aber nur für mehrere Routen zum gleichen Ziel

 

[TheBadFish]

Same shit, different day.

Ich hab die Box per Recovery Image vollständig zurückgesetzt. Anschließend händisch alle Einstellungen gemacht. Danach das Stinkylinux Image sowie die Freetz 1.1rc runtergeladen und ein neues Image erzeugt.

Folgende Einstellungen:
Box 7270
16MB (ist auch eine, hab ich gecheckt.)
Replace Kernel.
Pakete: WOL syslogd pptp tcpdump tcp2dns

Auf die jungfräuliche Box aufgespielt stehe ich jetzt wieder genau da, wo ich vorher auch schon stand.

Zusätzlich habe ich noch etwas ausprobiert. Ich habe im letzen Versuch die Internetverbindung per Timeout von 30s getrennt. Hier wurde bei einem Reconnect ja die Default Route nicht wieder gelegt. Jetzt habe ich die Box jedoch so umgestellt, dass sie kein pppoe mehr macht, sondern Inet über LAN1 bezieht. Beim zurückstellen auf Routerbetrieb mit pppoe ist die Default route dann wieder da.

Weiter gebracht hat mich das trotzdem nicht. :kotz:

/Edit: An der Metric hat sich auch nichts geändert.

 

[TheBadFish]

Ich bin der Lösung ein Stück näher, auch wenn ich es nicht ganz kapiere.

Hab hier noch ne alte FBF7141 rumliegen. Der hab ich soeben ein Freetz verpasst. Und zwar identisch (von den Paketen) mit dem auf der 7270.

Hier tut es. Zumindest komm ich mit der Box (über telnet auf der Konsole) an alle Server im Zielnetz per ping.

Die Box (7141) hat eine statische IP 192.168.179.2 und ist als reiner IP Client konfiguriert. Folgendermaßen sieht hier die Routingtabelle bei bestehender PPTP Connection aus:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.178.142 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   192.168.178.142 255.255.255.0   UG    0      0        0 ppp0
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         192.168.179.1   0.0.0.0         UG    9      0        0 lan

Die Frage ist jetzt, was muss ich an der Hauptbox (192.168.179.1) einstellen, dass alle Pakete aus dem lokalen Netzwerk für das Netz 192.168.178.0 an die "PPTP-Box" (192.168.179.2) weitergeleitet werden?

ein

route add -net 192.168.178.0 netmask 255.255.255.0 gw 192.168.179.2 dev lan

reicht anscheinend nicht.

/Edit: Mit dem ursprünglichen Thema hat das hier ja nicht mehr allzu viel zu tun, ich mach morgen einen neuen Thread auf. Danke für die Hilfe.

 

[zandy]

Hallo BadFish,

Ich habe genauso das gleiche Problem und wurde es gern lösen. Leider die Situation ist zu kompliziert für mein Deutsch und ich muss es aber in Englisch erklären:

I think that freetz is not starting pptp correctly. I've tried to start pptp from the shell ("pptp my-vpn-server") and get an error "sh: /bin/ip: not found" which suggests to me that although the connection is established OK, the routing tables are not being properly setup because the command is not there to do so. This seems to fit with your situation above where you are having to try and manipulate the routing tables manually.

Looking further, /bin/ip should be a part of busybox and the option is selected under "make menuconfig", but does not get through to the firmware image and neither is it listed under "help". Is the program there on your shell?

If not, then my guess is that the patch fixes a part but not all of the problem. If so, then I'm not sure where to go from here.

I hope this helps get a bit further.

Andy

PS
Antworte in Deutsch bitte schreiben

 

[stinkstiefel]

@TheBadFish Bezüglich der Route für 192.168.178.0 auf der 7141 siehe #25 ansonsten ist tcpdump dein Freund um zu prüfen wo es klemmt. Dabei solltest du dich aber erst einmal nur auf Echo Requests zum PPTP-Server konzentrieren.

 

[TheBadFish]

Zum Thema 7270 und pptp: Ich denke dass hier tatsächlich ein Bug vorliegt. Eventuell wäre ein Bug Ticket angebracht. Aber morgen, nicht mehr heute.

@zandy: Ich bekomme den selben Fehler wenn ich versuche pptp von Hand zu starten. Verwende ich das Startup Skript in /etc/init.d/rc.pptp dann bekomme ich keine Fehler. Auch die Ausgaben der syslog bringen mich nicht weiter. Auch nicht wenn ich im Debugmode starte (debug dump logfd 2 nodetach).
In der Routingtabelle hab ich aus einiges rumgemacht, wie du an der Menge Posts zu diesem Thema siehst. Weitergebracht hat es micht nicht. Auf der 7141 hatte ich in dieser Hinsicht übehaupt keine Probleme, es lief ohne die Kernelrouten manuell zu verändern

@Stinkstiefel: Jau, genau deshalb hab ich tcpdump mit reingepackt.


@all: Schön wäre zu wissen, ob es jemand geschafft hat, pptp auf der 7270 ans laufen zu kriegen.

Gute Nacht zusammen, falls noch jemand wach ist.