Poptop VPN mit MDA über GPRS bricht bei VNC zusammen
Hi zusammen,
Ich habe ein Problem mit der Einwahl über Windows Mobile (2003&5) uber eine PPTP VPN Verbindung. Wir habe einen installierten Poptop PPTP Linux Server der für die VPN-Einwahl in mein Netzwerk benutzt wird. Das funktioniert auch von Windows Rechnern aller Art einwandfrei.
Wir wollen die VPN-Leitung auch über unsere MDA Mobile-Phones nutzen. Die Authorisierung und die Verbindung über Telnet klappt!! Die Verbindung bricht augenblicklich zusammen, sobald man versucht über VNC oder Terminalverbindung ins Netz zu gelangen. Ich vermute irgendwo diese MTU/MRU Einstellung, das es etwas mit der Packetgröße und GPRS zu tun hat. Habe mit der Einstellung schon rumgespielt, komme aber nicht weiter. Wir benutzen T-Mobile und Eplus als Provider. Der Log aus der Linux Kiste:
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Received PPTP Control Message (type: 15)
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Feb 01 01:01:01 rechner pppd[12841]: rcvd [LCP TermReq id=0x1]
Feb 01 01:01:01 rechner pppd[12841]: LCP terminated by peer
Feb 01 01:01:01 rechner pppd[12841]: cbcp_lowerdown
Feb 01 01:01:01 rechner pppd[12841]: Script /etc/ppp/ip-down started (pid 12867)
Feb 01 01:01:01 rechner pppd[12841]: sent [LCP TermAck id=0x1]
Feb 01 01:01:01 rechner pppd[12841]: Script /etc/ppp/ip-down finished (pid 12867), status = 0x0
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Received PPTP Control Message (type: 12)
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Made a CALL DISCONNECT RPLY packet
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Received CALL CLR request (closing call)
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: I wrote 148 bytes to the client.
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Sent packet to client
Feb 01 01:01:01 rechner pppd[12841]: Modem hangup
Feb 01 01:01:01 rechner pppd[12841]: Connection terminated.
Feb 01 01:01:01 rechner pppd[12841]: Connect time 0.7 minutes.
Feb 01 01:01:01 rechner pppd[12841]: Sent 656 bytes, received 1408 bytes.
Feb 01 01:01:01 rechner pppd[12841]: Exit.
Die POPTOP Einstellungen:
noipdefault
ipcp-accept-local
ipcp-accept-remote
debug dump
kdebug 1
auth
crtscts
lock
#modem
local
asyncmap 0
netmask 255.255.255.0
nodetach
#lcp-echo-interval 30
#lcp-echo-failure 4
#lcp-max-configure 60
#lcp-restart 2
idle 6000
noipx
file /etc/ppp/filters
require-chap
require-mppe
mppe-128 #neu
mppe-stateless #neu
require-chapms-v2 #neu
nopcomp
nodeflate
#noreplacedefaultroute
Vielen Dank im vorraus,
Stefan
Ich habe ein Problem mit der Einwahl über Windows Mobile (2003&5) uber eine PPTP VPN Verbindung. Wir habe einen installierten Poptop PPTP Linux Server der für die VPN-Einwahl in mein Netzwerk benutzt wird. Das funktioniert auch von Windows Rechnern aller Art einwandfrei.
Wir wollen die VPN-Leitung auch über unsere MDA Mobile-Phones nutzen. Die Authorisierung und die Verbindung über Telnet klappt!! Die Verbindung bricht augenblicklich zusammen, sobald man versucht über VNC oder Terminalverbindung ins Netz zu gelangen. Ich vermute irgendwo diese MTU/MRU Einstellung, das es etwas mit der Packetgröße und GPRS zu tun hat. Habe mit der Einstellung schon rumgespielt, komme aber nicht weiter. Wir benutzen T-Mobile und Eplus als Provider. Der Log aus der Linux Kiste:
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Received PPTP Control Message (type: 15)
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Feb 01 01:01:01 rechner pppd[12841]: rcvd [LCP TermReq id=0x1]
Feb 01 01:01:01 rechner pppd[12841]: LCP terminated by peer
Feb 01 01:01:01 rechner pppd[12841]: cbcp_lowerdown
Feb 01 01:01:01 rechner pppd[12841]: Script /etc/ppp/ip-down started (pid 12867)
Feb 01 01:01:01 rechner pppd[12841]: sent [LCP TermAck id=0x1]
Feb 01 01:01:01 rechner pppd[12841]: Script /etc/ppp/ip-down finished (pid 12867), status = 0x0
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Received PPTP Control Message (type: 12)
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Made a CALL DISCONNECT RPLY packet
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Received CALL CLR request (closing call)
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: I wrote 148 bytes to the client.
Feb 01 01:01:01 rechner pptpd[12840]: CTRL: Sent packet to client
Feb 01 01:01:01 rechner pppd[12841]: Modem hangup
Feb 01 01:01:01 rechner pppd[12841]: Connection terminated.
Feb 01 01:01:01 rechner pppd[12841]: Connect time 0.7 minutes.
Feb 01 01:01:01 rechner pppd[12841]: Sent 656 bytes, received 1408 bytes.
Feb 01 01:01:01 rechner pppd[12841]: Exit.
Die POPTOP Einstellungen:
noipdefault
ipcp-accept-local
ipcp-accept-remote
debug dump
kdebug 1
auth
crtscts
lock
#modem
local
asyncmap 0
netmask 255.255.255.0
nodetach
#lcp-echo-interval 30
#lcp-echo-failure 4
#lcp-max-configure 60
#lcp-restart 2
idle 6000
noipx
file /etc/ppp/filters
require-chap
require-mppe
mppe-128 #neu
mppe-stateless #neu
require-chapms-v2 #neu
nopcomp
nodeflate
#noreplacedefaultroute
Vielen Dank im vorraus,
Stefan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 26674
Url: https://administrator.de/contentid/26674
Ausgedruckt am: 14.11.2024 um 17:11 Uhr
1 Kommentar
Heikle Sache mit dem Windows Mobile...
Dabei gleich verschiedene Ansätze... Packetgrössen glaube ich nicht. Mann kann es leicht testen indem man die VPN funktionalitäten des PDA selbst nutzt. Hier muss mann Ihm noch bestimtme IP´s erlauben, damit er die Verbindung nicht abbricht, das geht bei Netzwerkeinstellungen Ausnahmen. Kommt der PDA selbst ins VPN ist die GPRS / EDGE / UMTS Packetgrösse kaum schuld.
Ich benutze beim VPN die virtuelle Modembrücke auf das EDGE Modem meiner QTEK 9090er und neu Fujitsu Siemens Pocket LOOX 7XX. Wenn ich einen Windows Client habe connecte ich mit dem Modem das ist zwar bizarre ... aber Microsoft hat dies darum gemacht damit auch andere, nicht Network taugliche Systeme den PDA als UMTS Gateway nutzen können. Zum Beispiel MP3 Player.
Hierbei connecte ich mittels dem Bluetooth Modem Interface als RAS mit dem Modem... als Einwahlnummer nutze ich statt dem ISP das Kommando: #99* dies gibt dem PDA an, das er nun die gegenwärtige Internetverbindung anstelle einer Einwahl nutzen soll. Bei den Modemeinstellungen kann es sein das man einen bestimmten Modemkommando String übergeben muss, der enthält den GPRS Knoten z.b. "GPRS.T-ONLINE.DE" oder so... ab dann ist die Intenetverbindung voll transparent, alles - angefangen von Skype, VNC etc hat dabei gegeht.... Ärgerlich ist das man das Modem UND NICHT DIE NETZWERKVERBINDUNG nutzen muss... um das UMTS auf den Notebook zu mappen.
Ein anderer Grund kann DNS im GPRS Netzwerk sein, bei T-Online gibt es ja bekanntlich immer undokumentierte restriktionen um consumer Services von Profi Services abzugrenzen. So löst DNS bestimmte Domains nicht auf, oder aber es wird auf das VPN Protokoll geprüft und dieses gleich unterbunden ... ob das heute anders ist kann ich nicht sagen aber ich erinnere mich an Zeiten da war es so... daher sollte man wahlweise mit der Domains und der IP experimentieren... aber ich denke das habt Ihr sicher längst alles probiert. Sollte die klassiche Einwahl via Modem auf den GRPS / UMTS wieder erwarten nichts bringen war es eher ein Timeout problem. Die Sessions werden im GPRS Knoten des Providers gecached... damit bei einem Signalverlust nicht leich alles vorbei ist... mies ist das Messenger Services wie Skype dann immer noch eingelogged bleiben... tagelang... und mann bei MSN auch via PDA mal kurz auf die Hotmaildaten kommt ohne das man meinte eingelogged zu sein... dieses Session Handling der Mobilfunkbetreiber wird bei bestimmten Protokollen / Routern / Distris berücksichtigt und kann dazu führen das der KeepAlife thread die Session schliest, wenn verdacht auf caching besteht.
Dabei gleich verschiedene Ansätze... Packetgrössen glaube ich nicht. Mann kann es leicht testen indem man die VPN funktionalitäten des PDA selbst nutzt. Hier muss mann Ihm noch bestimtme IP´s erlauben, damit er die Verbindung nicht abbricht, das geht bei Netzwerkeinstellungen Ausnahmen. Kommt der PDA selbst ins VPN ist die GPRS / EDGE / UMTS Packetgrösse kaum schuld.
Ich benutze beim VPN die virtuelle Modembrücke auf das EDGE Modem meiner QTEK 9090er und neu Fujitsu Siemens Pocket LOOX 7XX. Wenn ich einen Windows Client habe connecte ich mit dem Modem das ist zwar bizarre ... aber Microsoft hat dies darum gemacht damit auch andere, nicht Network taugliche Systeme den PDA als UMTS Gateway nutzen können. Zum Beispiel MP3 Player.
Hierbei connecte ich mittels dem Bluetooth Modem Interface als RAS mit dem Modem... als Einwahlnummer nutze ich statt dem ISP das Kommando: #99* dies gibt dem PDA an, das er nun die gegenwärtige Internetverbindung anstelle einer Einwahl nutzen soll. Bei den Modemeinstellungen kann es sein das man einen bestimmten Modemkommando String übergeben muss, der enthält den GPRS Knoten z.b. "GPRS.T-ONLINE.DE" oder so... ab dann ist die Intenetverbindung voll transparent, alles - angefangen von Skype, VNC etc hat dabei gegeht.... Ärgerlich ist das man das Modem UND NICHT DIE NETZWERKVERBINDUNG nutzen muss... um das UMTS auf den Notebook zu mappen.
Ein anderer Grund kann DNS im GPRS Netzwerk sein, bei T-Online gibt es ja bekanntlich immer undokumentierte restriktionen um consumer Services von Profi Services abzugrenzen. So löst DNS bestimmte Domains nicht auf, oder aber es wird auf das VPN Protokoll geprüft und dieses gleich unterbunden ... ob das heute anders ist kann ich nicht sagen aber ich erinnere mich an Zeiten da war es so... daher sollte man wahlweise mit der Domains und der IP experimentieren... aber ich denke das habt Ihr sicher längst alles probiert. Sollte die klassiche Einwahl via Modem auf den GRPS / UMTS wieder erwarten nichts bringen war es eher ein Timeout problem. Die Sessions werden im GPRS Knoten des Providers gecached... damit bei einem Signalverlust nicht leich alles vorbei ist... mies ist das Messenger Services wie Skype dann immer noch eingelogged bleiben... tagelang... und mann bei MSN auch via PDA mal kurz auf die Hotmaildaten kommt ohne das man meinte eingelogged zu sein... dieses Session Handling der Mobilfunkbetreiber wird bei bestimmten Protokollen / Routern / Distris berücksichtigt und kann dazu führen das der KeepAlife thread die Session schliest, wenn verdacht auf caching besteht.