FBF7270 - eine PPTP Verbindung zum VPN aufbauen

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Danke fuer die ausfuehrliche Erklaerung. Die Gegenstelle ist tatsaechlich "vpn.blackvpn.com".
Ich habe alles so eingegeben wie oben beschrieben und dann durch das folgendes ergaenzt:

1) route del -net default
2) route add -net default dev ppp0

Die Verbindung bleibt bestehen und laut mehreren Internetseiten, z.B. http://www.ipaddresslocation.org/ habe ich US IP.

Allerdings wenn ich zu www.netflix.com gehe bekomme ich weiterhin "You cannot switch to Netflix from this location..".

Kann es sein dass hier weiterhin noch was fehlt?

Mein Routing sieht folgendermassen aus:


route -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
208.100.1.12 * 255.255.255.255 UH 0 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 0 0 0 dsl
41.240.238.224 * 255.255.255.255 UH 0 0 0 dsl
208.100.1.26 * 255.255.255.255 UH 0 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 0 0 0 dsl
172.16.21.1 * 255.255.255.255 UH 0 0 0 ppp0
192.168.178.201 * 255.255.255.255 UH 0 0 0 dsl
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

UND ueber traceroute bekomme ich


/var/mod/root # traceroute www.netflix.com
traceroute to www.netflix.com (208.75.79.17), 30 hops max, 38 byte packets
1 172.16.21.1 (172.16.21.1) 320.776 ms 312.903 ms 333.608 ms
2 ip2.208-100-1.static.steadfast.net (208.100.1.2) 322.689 ms 335.670 ms 320.425 ms
3 * * *
4 10ge5-4.fr1.ord.llnw.net (206.223.119.123) 321.219 ms 337.001 ms 345.276 ms
5 tge2-1.fr3.sjc.llnw.net (69.28.171.66) 379.772 ms tge13-3.fr3.sjc.llnw.net (69.28.189.21) 382.968 ms tge2-1.fr3.sjc.llnw.net (69.28.171.66) 370.067 ms
6 tge5-1.fr4.sjc.llnw.net (69.28.171.210) 374.022 ms tge9-1.fr4.sjc.llnw.net (69.28.189.25) 388.499 ms tge1-3.fr4.sjc.llnw.net (69.28.172.77) 380.702 ms
7 netflix.tge7-4.fr4.sjc.llnw.net (69.28.179.74) 384.147 ms 382.921 ms 376.723 ms
8 te1-7.csrt-agg01.dc2.prod.netflix.com (69.53.230.230) 374.250 ms 377.842 ms 384.069 ms
9 www.dc2.netflix.com (208.75.79.17) 386.734 ms 387.583 ms 390.887 ms
 
Scheint zu passen. Da verrät dich wohl dein Browser
 
Es hat zwar vermutlich nichts mit Netflix zu tun, aber woher kommt dieser Eintrag?
Code: 
192.168.178.201 * 255.255.255.255 UH 0 0 0 dsl
Normal sollte das eine lokale Adresse sein und nicht über DSL erreichbar.
 
Also erstmal vielen Dank. Es scheint im Prinzip zu funktionieren zumindest ueber Mac/FireFox. Ich werde es in den naechsten Tagen richtig Testen und bestaetigen.
Ein Paar Fragen haette ich noch:

1) Keine Ahnung woher der 192.168.178.201 Eintrag kommt aber dieser ist "permanent" - Wie werde ich es los? ("route del 192.168.178.201" entfernt es aber nach'm Reset ist dieser wieder da)
2) Ich wuerde gerne das ganze Automatisierien, d.h. wenn ich PPTP auf der Freetz-Webseite starte sollen die oben besprochenen Befehle automatisch als "Script" ausgefuehrt werden und wenn ich PPTP stoppe soll alles zum Urspruenglichen-setup zurueckgehen (ueber ein Script). Ich vermute es geht mit "ip-up" und "ip-down" aber

a) Darf man diese Dateien manuell modifizieren, und
b) Um alles zurueckzusetzen, waere es korrekt folgendes einzugeben:

route del -net default (ich vermute die alten "Routen" sollten ja noch bestehen)
route add -net default dev dsl
iptables ?

und dann evtl. (aus Sicherheitsgruenden?)

route del -host 208.100.1.12
route del -host 208.100.1.26
 
Du darfst mit Deiner Box machen, was Du willst :)

Iptables Regeln werden mit -D entfernt, siehe "man iptables".

Wenn der Eintrag mit der .201 nicht stört, dann laß ihn stehen. Ansonsten, hast DU noch andere Änderungen an der Box? Etwas in debug.cfg drin?
 
Danke RalfFriedl. Es laeuft, aber leider mit einigen Problemen. Die Verbindung bricht oft ab.

Ueber cat /var/log/messages bekomme ich oft so etwas:

[Edit frank_m24: Bitte benutzt CODE Tags für solche Ausgaben.]
Code: 
Mar  3 19:21:02 fritz daemon.notice pppd[11051]: pppd 2.4.4 started by root, uid 0
Mar  3 19:21:03 fritz daemon.info pppd[11051]: Using interface ppp0
Mar  3 19:21:03 fritz daemon.notice pppd[11051]: Connect: ppp0 <--> /dev/pts/0
Mar  3 19:21:03 fritz daemon.notice pptp[11053]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Mar  3 19:21:03 fritz daemon.notice pptp[11060]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Mar  3 19:21:03 fritz daemon.notice pptp[11060]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Mar  3 19:21:03 fritz daemon.notice pptp[11060]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Mar  3 19:21:04 fritz daemon.notice pptp[11060]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Mar  3 19:21:04 fritz daemon.notice pptp[11060]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Mar  3 19:21:04 fritz daemon.notice pptp[11060]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 48384).
Mar  3 19:21:05 fritz daemon.notice pppd[11051]: CHAP authentication succeeded
Mar  3 19:21:06 fritz daemon.notice pppd[11051]: MPPE 128-bit stateless compression enabled
Mar  3 19:21:07 fritz daemon.notice pppd[11051]: local  IP address 172.16.23.14
Mar  3 19:21:07 fritz daemon.notice pppd[11051]: remote IP address 172.16.23.1
Mar  3 19:21:24 fritz daemon.info hostapd: ath0: STA cc:08:e0:a3:f9:3c IEEE 802.11: associated
Mar  3 19:21:24 fritz daemon.info hostapd: ath0: STA cc:08:e0:a3:f9:3c WPA: pairwise key handshake completed (RSN)
Mar  3 19:21:30 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 88 (expecting 87, lost or reordered)
Mar  3 19:21:36 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 111 (expecting 110, lost or reordered)
Mar  3 19:21:54 fritz daemon.info hostapd: ath0: STA cc:08:e0:a3:f9:3c IEEE 802.11: disassociated
Mar  3 19:21:59 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 326 (expecting 325, lost or reordered)
Mar  3 19:21:59 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 328 (expecting 327, lost or reordered)
Mar  3 19:21:59 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 331 (expecting 330, lost or reordered)
Mar  3 19:22:02 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 402 (expecting 401, lost or reordered)
Mar  3 19:22:03 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 415 (expecting 414, lost or reordered)
Mar  3 19:22:04 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 425 (expecting 424, lost or reordered)
Mar  3 19:22:05 fritz daemon.notice pptp[11060]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Mar  3 19:22:07 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 445 (expecting 444, lost or reordered)
Mar  3 19:22:07 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 454 (expecting 453, lost or reordered)
Mar  3 19:22:07 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 458 (expecting 456, lost or reordered)
Mar  3 19:22:07 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 461 (expecting 460, lost or reordered)
Mar  3 19:22:07 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 469 (expecting 468, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 472 (expecting 471, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 473 (expecting 471, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 474 (expecting 471, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 475 (expecting 471, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 476 (expecting 471, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11053]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 477 (expecting 471, lost or reordered)
Mar  3 19:22:08 fritz daemon.notice pptp[11060]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Mar  3 19:22:08 fritz daemon.notice pptp[11060]: anon log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
Mar  3 19:22:08 fritz daemon.notice pptp[11060]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Mar  3 19:22:08 fritz daemon.notice pptp[11060]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Mar  3 19:22:08 fritz daemon.notice pptp[11060]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Mar  3 19:22:08 fritz daemon.notice pppd[11051]: Modem hangup
Mar  3 19:22:08 fritz daemon.info pppd[11051]: Connect time 1.1 minutes.
Mar  3 19:22:08 fritz daemon.info pppd[11051]: Sent 62624 bytes, received 485903 bytes.
Mar  3 19:22:08 fritz daemon.err pppd[11051]: MPPE disabled
Mar  3 19:22:08 fritz daemon.notice pppd[11051]: Connection terminated.
Mar  3 19:22:08 fritz daemon.info pppd[11051]: Exit.
Was kann man da machen? Haengt das mit dem Standard MTU-Wert zusammen (1500)?
Falls ja, wo kann man diesen setzen (ich dachte diese wuerde fuer den ppp0 Interface in einen der options.pptp/d stehen?
 
Es könnte an MTU liegen, 1500 ist tatsächlich etwas viel.

Trage mal bei den pppd Optionen "mtu 1400" ein. Wenn das hilft, kannst Du Dich mit dem Wert hoch arbeiten, so weit, wie es geht. Der Höchstwert für MTU mit PPPoE ist 1492. Bei PPTP über PPPoE könnte es bis 1476 funktionieren.
 
Habe den Wert MTU 1400 eingetragen. Leider sind die Bufferprobleme und der Zusammenbruch des Tunnels gleichgeblieben.

ifconfig zeigt

Code: 
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:172.16.21.24  P-t-P:172.16.21.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1400  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:70 (70.0 B)  TX bytes:208 (208.0 B)
[Edit frank_m24: Bitte benutzt CODE Tags für solche Ausgaben.]

Ueber cat /var/log/messages bekomme ich weiterhin:

Code: 
Mar  4 23:35:12 fritz daemon.notice pppd[20346]: pppd 2.4.4 started by root, uid 0
Mar  4 23:35:12 fritz daemon.info pppd[20346]: Using interface ppp0
Mar  4 23:35:12 fritz daemon.notice pppd[20346]: Connect: ppp0 <--> /dev/pts/0
Mar  4 23:35:12 fritz daemon.notice pptp[20348]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Mar  4 23:35:13 fritz daemon.notice pptp[20355]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Mar  4 23:35:13 fritz daemon.notice pptp[20355]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Mar  4 23:35:13 fritz daemon.notice pptp[20355]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Mar  4 23:35:14 fritz daemon.notice pptp[20355]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Mar  4 23:35:14 fritz daemon.notice pptp[20355]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Mar  4 23:35:14 fritz daemon.notice pptp[20355]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 40320).
Mar  4 23:35:15 fritz daemon.notice pppd[20346]: CHAP authentication succeeded
Mar  4 23:35:16 fritz daemon.notice pppd[20346]: MPPE 128-bit stateless compression enabled
Mar  4 23:35:17 fritz daemon.notice pppd[20346]: local  IP address 172.16.21.24
Mar  4 23:35:17 fritz daemon.notice pppd[20346]: remote IP address 172.16.21.1
Mar  4 23:36:10 fritz daemon.info hostapd: ath0: STA 60:33:4b:0b:4d:43 WPA: group key handshake completed (RSN)
Mar  4 23:36:14 fritz daemon.notice pptp[20355]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Mar  4 23:37:05 fritz daemon.notice pptp[20348]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 84 (expecting 83, lost or reordered)
Mar  4 23:37:08 fritz daemon.notice pptp[20348]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 91 (expecting 90, lost or reordered)
Mar  4 23:37:10 fritz daemon.notice pptp[20348]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 125 (expecting 123, lost or reordered)
...
Mar  4 23:37:15 fritz daemon.notice pptp[20348]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 489 (expecting 482, lost or reordered)
Mar  4 23:37:17 fritz daemon.notice pptp[20355]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Mar  4 23:37:17 fritz daemon.notice pptp[20355]: anon log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
Mar  4 23:37:17 fritz daemon.notice pptp[20355]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Mar  4 23:37:17 fritz daemon.notice pptp[20355]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
Mar  4 23:37:17 fritz daemon.notice pptp[20355]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Mar  4 23:37:17 fritz daemon.notice pppd[20346]: Modem hangup
Mar  4 23:37:17 fritz daemon.info pppd[20346]: Connect time 2.0 minutes.
Mar  4 23:37:17 fritz daemon.info pppd[20346]: Sent 68886 bytes, received 410163 bytes.
Mar  4 23:37:17 fritz daemon.err pppd[20346]: MPPE disabled
Mar  4 23:37:17 fritz daemon.notice pppd[20346]: Connection terminated.
Mar  4 23:37:17 fritz daemon.info pppd[20346]: Exit.

Kann man da noch etwas anderes probieren?
 
Anscheinend gehen Pakete unterwegs verloren. Solange sich das in Grenzen hält, sollte es kein ernstes Problem sein, obwohl es die Übertragung bremst.

Aber dann kommt auch noch "peer has closed", damit ist die Verbindung beendet.
Passiert das grundsätzlich, oder nur, wenn Du auch Daten überträgst? Wobei 400-500 Pakete nicht wirklich viel sind.
 
Es passiert nur wenn ich Daten uebertrage (z.Zeit Videodaten von Netflix). Die Verbindung bleibt erhalten meistens zwischen 5-10 Minuten, manchmal aber viel laenger. Wenn ich den Tunnel nur offen lasse (keine Daten) bleibt die Verbindung laenger erhalten.

Ich habe auch mit BlackVPN gesprochen wegen des Log-files. Sie meinten nur sie empfehlen grundsaetztlich OpenVPN statt PPTP.
Komischerweise habe ich die Verbindungsprobleme ueber PPTP auf dem Mac nicht gehabt.

Ich will im Moment noch nicht auf OpenVPN umsteigen.. nach all der Muehe will ich erstmal (hoffentlich) spass haben :)
 
UPDATE:

Was eigentlich passierte ist das nach einiger Zeit (5-10min) entweder der VPN-Tunnel oder Default-Route verschwunden sind (laute route -e).

Ich habe folgendes probiert:

1) Freetz 1.1.4 installiert um hoffentlich neuere PPTP und entsprechende LIBs zu haben
2) Tor de-aktiviert (im Log stand oft "our IP has changed"). Hat zwar wahrscheinlich nichts mit PPTP zu tun..

2x Filme spaeter laeuft alles wie es soll ohne Verbindungsprobleme. Es gehen zwar noch immer Pakete verloren aber davon merke ich nichts im Video.
Danke fuer die Hilfe !
 
Lieber Herr Gesangsverein, das ist EXAKT das, was ich machen will und der thread hier hilft hilft hilft. DANKE!
 
joa ich denke das ist auch das wonach ich suche nur versteh ich kein wort von dem was ihr da sprecht oO

welches freetz image empfehlst du? oder würdest du gar dein freetz image bereit stellen? ich hab keine ahnung vom Programmieren.. ggf auch deine config natürlich ohne deine zugangsdaten.. infos was was ist wäre ggf hilfreich?
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 686 (Mitglieder: 12, Gäste: 674)

Neueste Beiträge

Statistik des Forums

Themen
246,426
Beiträge
2,251,932
Mitglieder
374,163
Neuestes Mitglied
Wolli47
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