[Problem] Internet mit FritzBox 7390 über VPN-Service via PPTP

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
O

OliK79

Neuer User
Mitglied seit
25 Feb 2013
Beiträge
3
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

seit kurzem versuche ich, mittels Freetz meine Fritz!Box 7390 als Client in ein VPN einzuloggen. Im Grunde ist das Problem fast 1-zu-1 mit dem hier beschriebenen identisch:

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

Letztendlich will ich ebenso allen Internet-Traffic über die VPN-Server leiten. Jetzt habe ich ein Freetz-Image gebastelt, das mit "replace kernel", "pptp", "pppd", und "iptables" kompiliert wurde. Soweit hat auch alles funktioniert, ich konnte problemlos flashen.

Die Log-Ausgabe sieht m. E. auch erst einmal gut aus. Die Ausgabe, die ich nach dem Start von pptp über das WebIF erhalte:

Code: 
root@fritz:/var/mod/root# tail -f /var/log/messages
Feb 25 16:06:01 fritz daemon.info hostapd: ath1: STA e0:f8:47:09:fb:1e WPA: group key handshake completed (RSN)
Feb 25 16:06:01 fritz daemon.info hostapd: ath0: STA 40:30:04:9a:33:e3 WPA: group key handshake completed (RSN)
Feb 25 16:06:01 fritz daemon.info hostapd: ath1: STA 8c:2d:aa:70:8d:40 WPA: group key handshake completed (RSN)
Feb 25 16:06:02 fritz daemon.info hostapd: ath0: STA 18:e7:f4:ac:f1:b3 WPA: group key handshake completed (RSN)
Feb 25 16:16:01 fritz daemon.info hostapd: ath0: STA b4:b5:2f:1a:24:fb WPA: group key handshake completed (RSN)
Feb 25 16:16:01 fritz daemon.info hostapd: ath1: STA 00:1d:73:c9:36:79 WPA: group key handshake completed (RSN)
Feb 25 16:16:01 fritz daemon.info hostapd: ath0: STA 40:30:04:9a:33:e3 WPA: group key handshake completed (RSN)
Feb 25 16:16:01 fritz daemon.info hostapd: ath1: STA 8c:2d:aa:70:8d:40 WPA: group key handshake completed (RSN)
Feb 25 16:16:01 fritz daemon.info hostapd: ath1: STA e0:f8:47:09:fb:1e WPA: group key handshake completed (RSN)
Feb 25 16:16:01 fritz daemon.info hostapd: ath0: STA 18:e7:f4:ac:f1:b3 WPA: group key handshake completed (RSN)
Feb 25 16:19:02 fritz daemon.notice pppd[4484]: pppd 2.4.5 started by root, uid 0
Feb 25 16:19:02 fritz daemon.debug pppd[4484]: using channel 10
Feb 25 16:19:02 fritz daemon.info pppd[4484]: Using interface ppp0
Feb 25 16:19:02 fritz daemon.notice pppd[4484]: Connect: ppp0 <--> /dev/pts/3
Feb 25 16:19:02 fritz daemon.notice pptp[4486]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Feb 25 16:19:02 fritz daemon.notice pptp[4493]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Feb 25 16:19:02 fritz daemon.notice pptp[4493]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Feb 25 16:19:02 fritz daemon.notice pptp[4493]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Feb 25 16:19:03 fritz daemon.debug pppd[4484]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x506b1b78> <pcomp> <accomp>]
Feb 25 16:19:03 fritz daemon.notice pptp[4493]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Feb 25 16:19:03 fritz daemon.notice pptp[4493]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Feb 25 16:19:03 fritz daemon.notice pptp[4493]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 5888).
Feb 25 16:19:03 fritz daemon.debug pppd[4484]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x1d097bf9> <pcomp> <accomp>]
Feb 25 16:19:03 fritz daemon.debug pppd[4484]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x1d097bf9> <pcomp> <accomp>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x506b1b78> <pcomp> <accomp>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [LCP EchoReq id=0x0 magic=0x1d097bf9]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [LCP EchoRep id=0x0 magic=0x506b1b78]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [CHAP Challenge id=0x62 <363a9b09551ec0030d4d198cc77caadb>, name = "pptpd"]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [CHAP Response id=0x62 <22354ab0a4c2f5efd1b01aeb2134755e000000000000000070da00cc644a402444a9c0cc3faff37ecf25594c21b8a28f00>, name = "p6926359"]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [CHAP Success id=0x62 "S=24CB3CA2E100CEA5C4410A455B317470EFCA55BC"]
Feb 25 16:19:04 fritz daemon.notice pppd[4484]: CHAP authentication succeeded
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [CCP ConfReq id=0x1 <mppe +H +M +S +L -D +C>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
Feb 25 16:19:04 fritz daemon.notice pppd[4484]: MPPE 128-bit stateless compression enabled
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.178.1>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [IPCP ConfReq id=0x1 <addr 10.1.1.1>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [IPCP ConfAck id=0x1 <addr 10.1.1.1>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [IPCP ConfReq id=0x2 <addr 192.168.178.1>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [IPCP ConfNak id=0x2 <addr 10.1.1.20>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: sent [IPCP ConfReq id=0x3 <addr 10.1.1.20>]
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: rcvd [IPCP ConfAck id=0x3 <addr 10.1.1.20>]
Feb 25 16:19:04 fritz daemon.notice pppd[4484]: local  IP address 10.1.1.20
Feb 25 16:19:04 fritz daemon.notice pppd[4484]: remote IP address 10.1.1.1
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: Script /etc/ppp/ip-up started (pid 4494)
Feb 25 16:19:04 fritz daemon.debug pppd[4484]: Script /etc/ppp/ip-up finished (pid 4494), status = 0x0
Feb 25 16:20:04 fritz daemon.notice pptp[4493]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 25 16:21:04 fritz daemon.notice pptp[4493]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 25 16:22:04 fritz daemon.notice pptp[4493]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 25 16:23:04 fritz daemon.notice pptp[4493]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 25 16:24:04 fritz daemon.notice pptp[4493]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 25 16:25:04 fritz daemon.notice pptp[4493]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.

Danach bin ich erfreulicherweise noch online, allerdings nicht mit VPN-IP.

Nachdem ich (als ersten Schritt) einfach mal sämtlichen Traffic mit Ziel ausserhalb des lokalen LANs über das VPN leiten möchte, hatte ich zunächst
Code: 
route add default dev ppp0
versucht. Das führt aber (ähnlich wie im verlinkten Beitrag) dazu, dass das Internet nicht mehr erreichbar ist, weder von der Fritz!Box aus noch von einem angeschlossenen Client. Im oben verlinkten Beitrag wurde als Lösung genannt, das Routing mittels
Code: 
pppd call pptp && iptables -t nat -A POSTROUTING -j MASQUERADE && route add default dev ppp0
zu konfigurieren.

Allerdings hat das bei mir leider nicht geholfen. Im Moment bekomme ich auch folgende Fehlermeldung beim Anzeigen der Tabelle "nat":

Code: 
root@fritz:/var/mod/root# iptables -vnL -t nat
iptables v1.4.11.1: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Angeblich soll das ein Hinweis auf fehlendes "Replace Kernel" sein, aber das hatte ich definitiv aktiviert.

Mein Output von route bei hergestellter Verbindung ohne irgendeine Anpassung der Default Route sieht folgendermaßen aus:

Code: 
root@fritz:/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
62.156.60.89    *               255.255.255.255 UH    2      0        0 dsl
192.168.178.201 *               255.255.255.255 UH    2      0        0 dsl
10.1.131.1      *               255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     0      0        0 dsl

Momentan bin ich leider ziemlich ratlos, was ich jetzt noch testen kann. Zugegebenermaßen bin ich auch kein VPN-Spezialist :(

Vielen Dank schonmal im Voraus für alle erdenklichen Hinweise :)

Viele Grüße,
Oli
 
Hallo,

das korrekte Funktionieren des nat-Moduls könnte hiermit zu tun haben ... falls das so ist/wäre, sieht das nach meinem Verständnis für die 7390 schlecht aus.
Grüße,

JD.
 
Hallo,

ohje, das klingt nicht gut. Das muss ich mir später mal genauer durchlesen... In diesem Fall könnte ich mir dann natürlich das weitere Nachforschen sparen.

Vielen Dank trotzdem :)

Viele Grüße,
Oli
 
Ich weiß nicht, inwiefern das Nat-Modul in Abhängigkeit vom geladenen xt-state steht ...
Hast Du das nat-Modul denn ins Image gebaut oder als (nachladbares) Modul geflasht ... ?
Grüße,

JD.
 
Unabhängig vom NAT: Das Setzen der Defaultroute dürfte so nicht funktionieren.
Zum einen musst du das Routing so ändern, dass "das Bein zum ppptp-Server" über DSL und "nur den Rest durch das VPN" geht.
So macht das z.B. OpenVPN:
Code: 
route add <IP zum VPN-Server> dev dsl
route add -net 0.0.0.0/1  dev ppp0
route add -net 128.0.0.0/1 dev ppp0
 
@JD:

Wenn ich ehrlich sein soll, wusst ich gar nicht, dass ich da ein extra Modul brauche *schäm*
Ich werd da später nochmal reinschauen und nochmal testen. Danke schonmal!

@MaxMuster:

Das macht natürlich Sinn, wenn man drüber nachdenkt. Sonst erreich ich ja den VPN-Server gar nicht... Vilen Dank, probier ich ebenfalls aus :)
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 550 (Mitglieder: 40, Gäste: 510)

Neueste Beiträge

Statistik des Forums

Themen
246,776
Beiträge
2,257,253
Mitglieder
374,811
Neuestes Mitglied
Lazuli
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück