IPhone VPN->7270 VPN-> Hat das jemand?

[frank_m24]

Hallo,

hast du mal mitgesnifft, ob XAUTH überhaupt durchgeführt wird? Immerhin hast du ja auch einen FQDN angegeben, der reicht der Box üblicherweise in Zusammenhang mit den IP-Angaben für Phase 2. Und wenn der IPSecuritas clever ist, lässt er XAUTH einfach weg, solange kein Request dafür kommt. Und wenn die Box diesen Request nie sendet ...

 

[urtl]

nein mitgesnifft habe ich nicht...weiss leider auch nicht wie das geht (Tutorial?)

Das würde dann auch das Verhalten auf dem iPhone erklären, wenn dieses den XAUTH Request sendet und keine Antwort bekommt

Gruss

(PS: Sorry wegen dem Foto im letzten Thread...)

 

[daniel1974]

Hallo,

ich bin neu hier und habe mein Iphone noch nicht in der Hand ( ist schon bestellt) und habe mich hier in den ganzen Beiträgen schlaugemacht.

An dieser Stelle denke ich sollte man vielleicht aufhören zu warten bis Iphone mit einem neuen Soft kommt, denn nun ists schon 3.0 und das geht ja immernoch nicht.

Vielmehr sollte man sehen was man mit der Fritzbox machen kann, und da bin ich auch hier im Forum auf folgendes gestossen:

MAn kann die Firmware der Fritzbox erweitern, so dass eine PoPTop - PPTP-VPN-Server Verbindung mit dem Iphone möglich ist.

Die nötige Firmware Erweiterung ist zwar nich ganz so einfach durchzuführen, sollte aber mit den ganzen Tutorials dazu auch für Newbies machbar sein:

http://trac.freetz.org/

und hier weitere Infos mit jemandem bei dem es wohl schon funktioniert:

http://www.easyvdr-forum.de/forum/index.php?topic=6854.0

Ich hoffe ich habe hier die richtige Information gepostet, wäre interessant ob hier mal jemand das ausprobieren kann, ich warte noch auf mein iphone.

Beste Grüße,
Daniel

 

[dougi]

Feedback:

Es funktioniert. PPTP-Server in die Firmware integrieren und über verschlüßelte Verbindung von Iphone zur Fritzbox freuen

 

[Stone85]

@dougi: könntest du bitte deine Konfigdateien posten? Ist nicht so, dass ich (und sicher einige Andere) es so nicht versucht hätten Eine unverschlüsselte PPTP-Verbindung bekomme ich auch hin, aber scheinbar harpert es noch an den Konfigs.

Vielen Dank! Stone

 

[dougi]

Bei mir ging es zunächst auch nur unverschlüsselt. Entscheident für die verschlüsselte Verbindung war der Patch aus diesem Post http://www.ip-phone-forum.de/showthread.php?t=192328 im pptp-Server.
Damit habe ich eine neue Firmware erstellt und die Verschlüsselung mit diesen Einstellungen

# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
#require-mppe-128
# }}}
mppe required,stateless,no40,no56

in der options.pptp aktiviert.

Der Verschlüsselungsmodus im Iphone muss passend dazu auf "Automatisch" stehen.

Für weitere Fragen stehe ich gerne zur Verfügung.

Gruß Dougi

 

[Stone85]

@dougi: das hört sich gut an, ich werde es beim nächten Imagebau einbeziehen. Vielen Dank!

 

[HartmutB]

@dougi: das hört sich gut an, ich werde es beim nächten Imagebau einbeziehen. Vielen Dank!

Vielleicht noch als Ergänzung von einem "Newbi":

Ich habe (wegen der Informationen in diesem Thema) vor ca. 6 Wochen auf Basis 29.04.70freetz-1.1 auf meiner 7170 ebenfalls das VPN zu meinem ipod-Touch hinbekommen, bei der Version 1.1 waren *keine* Patches mehr nötig. Seit diesem Zeitpunkt läuft es problemlos.

Die relevante Zeile in meiner options.pptp entspricht der von dougi.


Vielen Dank an alle Beteiligten einer Lösung in diesem Forum :groesste: ! Nach einer VPN-Verbindung von der 7170 zu meinem ipod-Touch (vielleicht irgendwann auch mal zu einem iphone) habe ich lange gesucht, da darüber auch unsere KNX-Haussteuerung läuft, was ja "nicht ganz" unkritisch ist.


Gruß
Hartmut

 

[chrisb101]

@HartmutB: Kannst du mir kurz erläutern wie die Freetz auf die Box bekommen hast?

Welches KNX tool auf dem ipod Touch und welches Gateway verwendest du zuhause?

Gruss
Chris

 

[HartmutB]

@HartmutB: Kannst du mir kurz erläutern wie die Freetz auf die Box bekommen hast?

Welches KNX tool auf dem ipod Touch und welches Gateway verwendest du zuhause?

Hallo Chris,
die Freetz-Firmware habe ich wie unter http://trac.freetz.org/ beschrieben erstellt und dann über den normalen Firmware-Update auf die Box übertragen.

Ich habe die Firmware dabei mit StinkyLinux in einer VMware-Session auf meinem Windows XP Rechner gebaut. Alles ist gut auf der Freetz-Seite beschrieben, ein wenig Linux-Erfahrung hilft aber durchaus. Mit Einlesen in die Materie hat es so einen Samstag ab spätem Frühstück gedauert


Ich verwende einen Gira Homeserver, der stellt eine speziell auf das iphone angepasste Webseite bereit ("PocketVisu"), damit wird alles gesteuert. Auf dem iphone / touch ist es mehr oder weniger nur eine aufgerufene Webseite, die aus Sichheitsgründen durch das VPN getunnelt wird.


Gruß
Hartmut

 

[chrisb101]

Hi,

so das hab ich hinbekommen. Bei mir auf der box läuft nun:
54.04.76freetz-1.1-stable

Allerdings aus dem branch und nicht aus dem tag, denn dort gabs die .76 fw noch net.

Nun fehlen mir aber sämtliche Packages, welches ist den für die vpn Verbindung nochwendigt? pptp, openvpn, etc?
Wie kann ich den Kernel ersetzen?

Gruss
Chris

 

[chrisb101]

So ich antworte mir mal selbst. ;-)
Nun hab ich das Paket pptpd mit im Image und die Fritzbox läuft noch.

Was ich nun als nächstes herausfinden muss, was trage ich in die Konfigurationsdateien ein. Über die WebUI bekomm ich folgende Meldung:
Konfiguration in der aktuellen Sicherheitsstufe nicht verfügbar!

Geht das nur per telnet?
Wie gehts nun genau weiter?

Gruss
Chris

 

[sackschlangen]

Hi,

ich greife hier mal auf, ich habe die Fritzbox erst ein paar Tage und war davor dd-wrt verwöhnt , egal, die hatte keine DECT und kein VoIP. Das erstellen der aktuellen FW inkl. PPTPD hat nach den Anleitungen von Euch und im freetz-wiki überraschend schnell funktioniert.

Zur Frage, die .conf-Dateien kannst Du per telnet oder ssh im Terminal ändern (das mit der Sicherheitsstufe, bzw. wo man diese verstellen kann, durchschaue ich auch nicht)

> vi /var/tmp/flash/ppp/options.pptpd

> vi /var/tmp/flash/ppp/pptpd.conf

> vi /var/tmp/flash/ppp/chap-secrets

zur Handhabung des Editors vi am besten googeln (crash-kurs: Kommandozeile ist ganz unten, 'i' schaltet Editiermodus ein, 'ESC' aus, ':w' schreibt die Datei, ':q' beendet)

Wie dem auch sei, funktionieren tut's bei mir trotzdem nicht, was ich aber feststelle, ist, sobald ich den pptpd Dienst aktiviere, geht die Internetverbindung hinter der Fritzbox total in die Knie.

Hier meine

pptpd.conf:

ppp /usr/sbin/pppd
option /etc/ppp/options.pptpd
bcrelay lan
localip 192.168.3.201
remoteip 192.168.3.210-219

und options.pptpd:

name VPNName          
netmask 255.255.255.0   
ms-dns 192.168.3.1      
nodefaultroute          
proxyarp                
lock                    
mtu 1000                
mru 1000                
network
auth                   
require-mschap-v2
mppe required,stateless,no40,no56

wenn ich das jetzt richtig verstehe, muss ich noch port 1723 freischalten (tcp und udp?!) und dann sollte es mit den Zugangsdaten aus chap-secrets funktionieren, oder?

Gruß

 

[joshi04]

Hallo zusammen,

ich beschäftige mich auch seit ein paar Tagen mit diesem Thema.

Die Sicherheitsstufe läßt sich durch

echo 0 > /tmp/flash/security

setzen.

Nähere Informationen dazu findet man aber auch hier:
http://trac.freetz.org/wiki/FAQ#KonfigurationinderaktuellenSicherheitsstufenichtverfügbar

Danach lassen sich die 3 Konfigurationsdateien auch komfortabel in der Web-Oberfläche bearbeiten.

Es fehlen noch zwei Weiterleitungen, um die Anfrage an den Server auf das interne Interface umzuleiten:

TCP-Port 1723 und GRE
Da die FritzBox solche Regeln auf sich selbst nicht zulässt kann man erst einem je eine Regel für eine andere IP-Adresse einrichten und dann nachher per SSH-Login (oder Telnet) auf die Box die Einträge ändern:
nvi /var/flash/ar7.cfg
( am besten mit Befehl /1723 suchen nach 1723)
Die Einträge stehen unter forwardrules.

(gefunden an dieser Stelle http://www.easyvdr-forum.de/forum/index.php?topic=6854.0;wap2)
Für diese Änderung braucht man dann allerdings doch vi-Kenntnisse.

Ich hatte anfangs Probleme, dass die Weiterleitung nicht funktionierte. Bei mir half der Hinweis, dass die Regeln möglichst als erste einzutragen seien. Ich hatte da vorher noch ein paar Regeln eingerichtet, die zwar inaktiv waren, aber anscheinden trotzdem störend waren. Nachdem ich sie gelöscht hatte, lief auf alle Fälle die Weiterleitung.
In der über Freetz aktivierten AVM-FW stehen derzeit nur noch die Ports 443 TCP (Remoteaccess) und 5060 UDP (SIP) vorher drin.

Ob der PPTPD richtig läuft, kann man auch schon mal von "intern" testen und schauen, ob man ohne das Forwarding über die FB sich mit dem PPTPD verbinden kann.

Dass der HTTP-Traffic bei aktiviertem PPTPD in die Knie geht, habe ich leider auch schon feststellen müssen. Interessanter Weise passiert das bei mir nur nach einiger Zeit des Traffics. Ping geht noch und auch DNS schein zu funktionieren. Der Ping an die URL, die im Browser keine Seite findet, wird trotzdem noch aufgelöst. Startet man den PPTPD dann wieder neu, läuft erstmal wieder alles. Ich habe schon ein wenig angefangen den HTTP-Traffic zu debuggen, allerdings bislang noch ohne Erkenntniss. Ist hier jemand schon weiter?


Darüber hinaus habe ich noch ein kleines Routingproblem:
Vom über VPN angebundenen iPhone kann ich derzeit noch keine Rechner im lokalen Netz erreichen.

@ sackschlangen: Welche IP hat die FB in Deiner Konfiguration?

Meine options.pptpd sieht etwas anders aus (bis aufs Routing und das oben genannte Problem läuft sie aber):

name VPNName
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
mppe required,no40,no56,stateless
ms-dns 192.168.120.10
proxyarp
lock
nobsdcomp 
novj
novjccomp

Der Vollständigkeit halber die pptpd.conf

ppp /usr/sbin/pppd
option /etc/ppp/options.pptpd
bcrelay lan
localip 192.168.120.10
remoteip 192.168.120.20-20

Die FB hat in dieser Konfigutation die IP 192.168.100.10 und auf der PPTPD-Konfig-Seite ist IP-Routing aktiviert mit dem Eintrag

192.168.100.0 255.255.255.0 192.168.120.20

Soweit ich derzeit verstanden habe, sollte der PPTP-Server und die Clients in einem anderen Subnetz sein, als das LAN.
Ich befürchte, ich muss mir das Thema proxyarp bzw. bcrelay nochmal genauer anschauen. Es sei denn, jemand hat an dieser Stelle eine schnelle Erklährung...

Schöne Grüße
joshi04

 

[sackschlangen]

Hi,

erstmal Danke für die vielen Infos, ich habe gestern auch weiter experimentiert und stehe jetzt im Prinzip ähnlich da, wie Du schreibst. Das mit der Sicherheitsstufe habe ich dann auch gefunden.

Die Ports konnte ich in der avm-firewall Weboberfläche (unter freetz) setzen, 1723 unter firewall (permit an 0.0.0.0) und GRE unter Forwarding ohne weitere Angaben. Die pptpd.conf habe ich wieder auf localip 192.168.3.1 (das ist die FB im LAN, obige Angaben sind Relikte aus Versuchen) geändert.

Nun bin ich soweit, dass ich mich innerhalb des LAN von einem Mac und vom iPhone aus über VPN per PPTP anmelden kann, von aussen, also wenn ich als IP die WAN-IP des DSL-Anschluss der FB angebe, funktioniert es jedoch nicht, egal, ob ich dies dann wieder von innerhalb des LAN, oder vom iPhone via GPRS mache, irgendwas wird da wohl nicht geroutet. Anpingen läßt sich die WAN-IP aber schon.

Was indessen als Hauptproblem bei mir bleibt, ist, dass die DSL-Verbindung bei starten des pptpd Dienstes sofort massiv in die Knie geht und sich erst bei deaktivieren wieder (sofort) erholt.

Unterschiedliche Subnetze für LAN und VPN kenne ich so nicht, wohl, dass man innerhalb der LANs, die durch den VPN-Tunnel verbunden werden unterschiedliche Subnetze haben muss (bei mir hat z.B. das Netz des VPN-Server 192.168.2.x, das aus dem der Client anruft 192.168.3.x), sonst gibt es Konflikte. Meine Erfahrung beziehe ich hier allerdings von einem funktionierenden pptpd-Server auf einem dd-wrt-Router einer anderen Baustelle.

Also bei mir stehen noch 2(3) Fragezeichen;
wieso geht die DSL-Verbindung in die Knie?
wieso wird die WAN-IP nicht auf die LAN-IP der FB geroutet?
(wie starte ich eigentlich den syslogd per default? /var/log/syslog fehlt bei mir, ich habe jetzt eine Log-Datei direkt unter options.pptpd per debug/logfile xyz.log angegeben, da steht aber dann logischerweise nicht alles drin)

Gruß,

sack

 

[sackschlangen]

Hi, ich antworte mir mal selbst:

Frage 3: mit einem manuellen ">syslogd -O /var/log/syslog" im Terminal kann ich das Syslog zeitweise einschalten, zeitweise reicht mir.
Frage 2: ich musste noch in der Freetz - avm-firewall die Port-Forwarding-Regel für Quellport 1723 an die Adresse 0.0.0.0:1723 ergänzen, danach werden VPN-Clients von außerhalb des LANs auch erhört

Frage 1: Offen!! - Wieso hängt die DSL-Verbindung der Rechner im Netz nach draussen, sobald ich den Dienst pptpd starte? Im syslog stehen keine auffälligen Meldungen, es scheint auch nichts mit der Namensauflösung zu tun zu haben, sondern mit der reinen Übertragungsrate. Google.de kann ich noch öffnen, die meisten anderen Seiten laden unendlich.

Hat keiner eine Idee? Keiner??

Hier nochmal meine aktuellen Configs:

pptpd.conf:

ppp /usr/sbin/pppd
option /etc/ppp/options.pptpd
debug
#stimeout 10
#noipparam
#logwtmp
bcrelay lan
localip 192.168.3.1
remoteip 192.168.3.210

options.pptpd:

debug
logfile /tmp/pppd-pptpd.log
name VPNName
netmask 255.255.255.0
ms-dns 192.168.3.1
nodefaultroute
proxyarp
lock
auth
#refuse-pap
#refuse-chap
#require-mschap
#require-mschap-v2
#require-mppe-40
#require-mppe-128
require-mschap-v2
#require-mppe-128
mppe required,stateless,no40,no56

 

[joshi04]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Moin,

da bist Du doch schon relativ weit. Denn wenn Du Dich von intern schon verbinden kannst, heißt es, dass es "nur" noch ein Routing-Problem in der FB ist und der iPhone-VPN-Client sich mit dem PPTPD einwandfrei verbindet.

Dass es keinen Unterschied macht, von intern oder extern mit der WAN-IP zu connecten, wird daran liegen, dass Du damit natürlich immer nur auf das WAN-Interface zugreifst, von dem natürlich unabhängig von der Quelle das Routing aufs interne Interface noch nicht funktioniert.

Wie erwähnt hatte ich anfangs das gleiche Problem. Also alles raus aus dem Forwardliste und dann nur noch die beiden Einträge für 1723 und GRE rein.
Ich habe folgende Reihenfolge: GRE-Regel, dann die für den Port (wer weiß, obs ggf. daran scheitert).
Ich habe bei meinen Recherchen aber auch gelesen, dass jemand die FB nur durch "komplettes Löschen" und neu Einrichten der Regeln zum routen überreden konnte. Was das aber genau bedeutet, weiß ich nicht, bei mir lief es ja so. Mein Eindruck ist, dass das Forwarding allgemein keine so stabile Geschichte zu sein scheint...
Der Vollständigkeit halber - vor den beiden Regeln für GRE und Port 1723 stehen bei mir noch die beiden Regeln wie in #54 beschrieben.
Ich habe zwar auch an 0.0.0.0 geforwarded, ggf. kannst Du aber auch nochmal probieren, die interne IP der FB zu verwenden.

Das Problem mit dem HTTP-Traffic habe ich leider auch immer noch. Interessant finde ich, dass bei mir das nur sporadisch auftritt. 2 mal ist es beispielsweise passiert, dass ich selbst die fritz.box:81 Seite nicht mehr erreichen konnte, um den PPTPD zu deaktivieren (ein reset hat geholfen). das ging schon mal. Darüber hinaus hat auf dem iPhone beim eingewählen VPN und "zusammengebrochenem" Traffic die Ping-App nicht mehr richtig funktioniert. Allerdings bin ich kurze Zeit später auch aus dem VPN rausgeflogen, vermutlich also nur ein Timeout. Mein derzeitiger Verdacht ist tasächlich, dass das Paket Poptop nicht einwandfrei läuft und das Routing total durcheinander bringt. Ein weiterer Hinweis darauf wäre, dass in besagtem Zustand das iPhone seine eigene Client-IP nicht mehr anpingen konnte (ok, siehe Timeout...).

Ich habe auch schon nach Alternativen zu Poptop geschaut (bislang ohne Erfolg). Es ist leider schon die aktuellste Version 1.3.4. in Freetz verwendet, sodass ich kurz davor bin, mal ein Ticket aufzumachen. Allerdings würde ich gerne noch ein paar mehr Informationen sammeln, woran es denn nun eigentlich scheitert.

Während ich das hier schreibe, ist das Ding schon wieder abgeschmiert. Meine Vermutung ist, dass der PPTPD abstürzt und damit den gesamten Traffic auf der FB unterbricht. Dieser Detailgrad ist für mich aber auch noch Neuland.

Syslogd läßt sich überigens beim kompilieren vom Image unter "web interface" mit einkompilieren, dann erscheint der log gleich unter dem Status Eintrag.

Alternativ läßt sich syslogd in der shell über

syslogd -O /var/log/sys.log

aktivieren.

Mit

tail -f sys.log

sieht man dann auch gleich online, was so passiert.

Ob die FB ein Temperaturproblem, sprich die CPU entsprechend ausgelastet ist, kann ich glaube ich auch ausschließen. Mit TOP sieht man, dass sich die FB auch bei aktiviertem PPTPD eher langweilt... (Also nicht wie bei TOR).

Mit HTTPFox habe ich mal geschaut, ob da überhaupt noch was passiert: "NS_ERROR_UNKNOWN_HOST" was wohl soviel heißt wie nichts geht mehr und selbst der DNS ist weg.

Sch...! meine FW schein heute einen wirklich schlechten Tag zu habe, denn sie ist gerade schon wieder abgeschmiert.
Ich fasse den Zustand während des Absturzes also nochmal zusammen (bitte nehmt Rücksicht bei der logischen Reihenfolge):
- alle Telnets auf die FB bleiben hängen.
- kein DNS mehr (keine Auflösung)
- Ping auf die FB -> keine Antwort
- keine Auffälligkeiten im Syslog oder TOP
- Ping auf die Client IP (an dem ich sitze) geht noch
- Ping auf die IP von einem anderen Rechner im Netz geht noch -> Der Switch in der FB schein also noch zu laufen.
- Das WLAN Modul geht ebenfalls noch (der Client an dem ich sitze ist per WLAN im Netz).
- DHCP habe ich vergessen zu testen. Beim nächsten Hänger.
Taurig ist das ganze irgendwie trotzdem.

Das Routing-Problem stelle ich also erstmal zurück, bis wir das andere gelöst haben. Ohne laufenden PPTPD brauche ich ja auch kein Routing ;-)

Ich werde am Wochenende mal alles neu Aufsetzten und die FB auf "Werkseinstellungen" zurücksetzten. Dann das Freetz mit nur Poptop kompilieren und schauen, ob er immer noch abschmiert. Alternativ gibt es ja auch noch den Trunk Branch zu probieren. Für heute ist aber erstmal Schluss. Nur noch FB ein letztes Mal durchstarten und den Beitrag einstellen...
Schöne Grüße,
joshi04

[Beitrag 2:]
Da haben wir uns wohl zeitlich überschnitten.

Sorry, die FW-Regeln habe ich total ausgeblendet! Ich habe unterschlagen, dass ich fürs Einrichten die FW erstmal auf Permit all gestellt habe, damit die als zusätzliche Fehlerquelle auszuschließen ist.

Doch noch was zum Routing:
Ich habe gesehen, dass bei Deiner Konfiguration sowohl remoteip als auch localip aus dem gleichen Subnetz kommen. Es kann sein, dass es damit bei mir auch schonmal funktioniert hat. Allerdings war ich aufgrund der Kommentare in der pptpd.conf irgnedwie auf dem Tripp, dass man das doch verkomplizieren kann, so dass am Ende garnichts mehr läuft. Aber das probiere ich nun wirklich erst morgen.

Wie Du schon sagtst, Frage 1 bleibt offen. Ich habe noch ne 3270 auf der ich auch nochmal probieren kann. Das ist aber nicht die präferierte Option, da sie nicht dauerhaft am Netz hängen soll. Ein Stromverbraucher reicht. Außerdem wäre Dir damit auch nicht geholfen.
Schöne Grüße,
joshi04

 

[sackschlangen]

Hi,

da ich keinen Bock habe, heute Nacht wieder spät mit verquollenen Augen ins Bett zu fallen, habe ich mich in der heutigen Folge () auf eine Fehleranalyse beschränkt.

D.h.

a) per SSH auf der Box >top laufen lassen, um zu schauen ob irgendwelche Ressourcenfressenden Prozesse laufen -> nichts auffälliges bei laufendem pptpd, die Box bleibt auch im LAN per WebUI und Terminal schnell erreichbar

b) Im Hintergrund auf meinem Rechner eine Linux-Distri gesaugt -> Downloadrate bleibt mit und ohne pptpd ähnlich hoch, ein Reconnect dauert mit aktiviertem pptpd aber häufig länger

c) verschiedene physische Rechner (Mac/WinXP/Linux) und verschiedene Browser verglichen, Seitenaufbau ist bei allen deutlich verlangsamt, sobald der pptp Dienst läuft

d) tatsächlich mal eine VPN Verbindung vom iPhone per GPRS auf die FB hergestellt und lokale Seiten angeklickt -> keine merkliche Auslastung der Box festzustellen, die Downloadgeschwindigkeit der Linux-Distri im Hintergrund ging etwas runter, aber nicht ungewöhnlich.

Das ganze müsste man mal fachmännischer im Terminal per traceroute oder weiss der Geier was machen, um zu sehen, ob vielleicht die Anzahl gleichzeitiger Verbindungen durch pptpd dezimiert wird oder so, dazu muss ich mich aber erstmal wieder schlau lesen.

Gruß,

Sack

 

[joshi04]

Moin,

ausnahmslos allen Anmerkungen (incl. geschwollenen Augen ;-) ) kann ich mich anschließen.
Ich habe noch keine neuen Erkenntnisse und bin gerade mal am Kompilieren. Mehr oder minder ist das aber auch nur "trial and error" :-(

Eine interessante Erkenntniss, die ich allerdings noch gewinnen konnte, ist dass die Performance, die die FB noch durchläßt bei mir definitiv tagesabhängig ist. Anfangs konnte ich über die Konfi-Seite wenigstend den deamon noch stoppen, was gestern definitiv nicht mehr lief.
Von daher darfst Du Dich noch glücklich schätzen, dass der Traffic "nur" etwas langsamer läuft.

Fürs tiefere Debuggen muss ich mich ebenfalls erst schlaulesen.

Ich melde mich wieder, wenn ich neue Erkenntnisse habe.

Gruß,
Joshi04

 

[joshi04]

Moin,

ich bin einen Schritt weiter:
Im Moment scheint PPTPD stabil zu laufen.

Wie bin ich vorgegangen?
- Zum Erstellen des Images habe ich Freetz-Stable-1-1 (revision 3762) benutzt.
- Bis auf den pptpd und die FW sind keine weiteren Pakete aktiviert.
- Patches sind folgende aktiv: remove help, assistant, usermand, patch usb names,
- Einstellungen gesichert
- FB mit recover zurückgesetzt
- Einstellungen zurückgespielt (klar besteht hier die Möglichkeit, sich alten kram wieder einzufangen, das wäre dann die nächste Stufe)
- Sicherheitlevel auf 0 setzten
- Konfigfiles ändern und PPTPD starten

Eigentlich habe ich damit nicht gerechnet, dass das "recovern" hilfreich ist. Vielleicht spielt auch die restriktive Auswahl der Pakete eine Rolle. Aber eigentlich ist das ja kein Windows... Ggf. liegt es auch an der derzeitigen Revision. Zusammenfassend habe ich leider keine Erklährung, warum es nun läuft.

Routing habe ich auch hinbekommen:
- Lokales LAN: 192.168.150.0 255.255.255.0, FB-IP 192.168.150.10
- Die IP für den Client (iPhone) wird anscheinend über die chap-secrets zugewiesen, z.B. 192.168.200.110
- In der pptpd.conf: localip: 192.168.200.100, remoteip 192.168.200.110-120, #bcrelay lan (deaktiviert), #proxyarp (deaktiviert)
- In der options.pptpd: ms-dns 192.168.150.10

Wie oben, bin ich auch hier etwas ratlos, warum das Routing läuft. Auf der Dienst-Seite ist kein Routing aktiviert. Einzig der Eintrag des DNS-Servers im lokalen Netz (erklärt aus meiner Sicht aber nur die Auflösung, nicht aber das Routing)könnte das erklären. Eigentlich dürfte das routing so nicht laufen.

Mir bleibt also unkar:
- Wozu ist die Festleung "remoteip", wenn die Client-IP doch über die Authentifizierung zugewiesen wird? (Zuweisung über die chap-secrets, routing aber über den Eintrag "remoteip"?)
- Warum läuft das routing in dieser Konf?
Wenn mir jemand das erklären kann, wäre ich natürlich trotzdem dankbar.
- Eigentlich soll man doch alle IP-Adressen aus dem lokalen Netz unter "localip" eintragen. Wieso kann ich also das gesammte Netz von Client erreichen?

Nunja, solange es funktioniert, sei es wie es ist. Manchmal kommt man mit "Ich probier einfach nochmal, dass der Ping so definitiv nicht durchkommt" doch ziemlich weit, auch wenn das nicht meine präferierte Methode ist.

Nächste Schritte werden nun sein, die FW entsprechend zu modifizieren, damit das Loch nicht ganz so groß ist.

Als denn,
joshi04