[gelöst] VPN-Verbindung über WWan zum Firmennetzwerk funktioniert nicht (Error 619)

[Joehittn]

Hellas!

Hab ein X61 Tablet (type 7762-74g) mit inkludiertem wwan (vista business). Neuen Treiber von der Telekom (vodafone dashboard 9.1.2.577) installiert, internet funkt (wenn auch relativ langsam).

Nun hab ich das Problem dass bei der Errichtung der VPN-Verbindung zum Firmennetzwerk über wwan immer nachdem die Verbindung zum Firmennetzwerk hergestellt wurde, die Verifizierung des Benutzernamens und Kennworts ca. 30 Sekunden stehen bleibt und dann kommt de Fehlermeldung "Getrennt. Fehler 619: Ein unbekannter Fehler ist aufgetreten."

Selbiges Problem tritt bei Sony sz7awnc unter Windows XP auf... (Wobei ich hier schon mal fuer ein paar Minuten eine Verbindung hinbekommen habe... die jetzt aber wieder nicht mehr funktioniert...)

Ich hab jetzt ein paar Stunden herumprobiert, gegoogelt und mir open-vpn-client, usw. ausprobiert, hat aber leider alles nichts geholfen.


Vielen Dank im Voraus für Eure Hilfe,

Joehittn


Edit:

Firewall hatte ich schon an- und ausgeschalten kein Unterschied.
Von der Workstation daheim, die sogar hinter einem Linksys-Router steht, kann ich ohne Probleme eine VPN-Verbindung aufbauen, also sollte das Problem client-seitig liegen.

 

[Eric]

Ich glaub du brauchst die Logfiles von deiner Firma.
So lässt sich nicht wirklich was dazu sagen.

 

[Crash Override]

Nur soviel: Wir setzen eine Watchguard auch für VPN ein. Der Client meldet unter Vista aber immer den gleichen Fehler wie bei dir. Unter XP gibt es dagegen keine Probleme. Unter Ubuntu 8.04 steht es noch auf meiner todo Liste, da dort nun auch WWAN mit umtsmon wunderbar läuft.

 

[Eric]

Welchen Client nutzt ihr? Der meines Wissens einzig funktionierende Client unter Vista ist der NCP Client. Cisco hat bis jetzt nur ne Beta draußen. (die auch nur unter 32bit läuft)

MfG Eric

 

[Joehittn]

der server-admin is leider grade auf urlaub, von daher komm ich grade nicht an logfiles...

jetzt hats wiedermal kurz geklappt, dann hab ich die verbindung wieder getrennt und wollte es nochmal probieren, dann kam wieder die uebliche fehlermeldung.

ich verwend den windows-internen vpn-clienten.
den npc-clienten hab ich mal kurz ausprobiert, aber der will von mir ne telefonnummer zur herstellung der verbindung... nur benoetigt das built-in wwan halt eigentlich keine einwahlnummer...

edit: ah... man muss anscheinend als verbindungsmedium "lan over IP" eingeben... aber dann kommt IKE-Fehler (Phase 1).

 

[Joehittn]

tagchen... ich hab das problem leider immer noch nicht loesen koennen... bitter, bitter, bitter...

hier der tcp-dump mit zusatzinformationen von unserem externen serverbetreuer:


------------------------------------

wie soeben besprochen sende ich Ihnen die "tcpdump"
Ausgaben zum vorhin durchgeführten PPTP VPN Einwahltest.

root@router:~ {504} $ tcpdump -n -i eth1 host 80.xxx.xxx.xxx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:50:33.392705 IP 80.xxx.xxx.xxx.49323 > 83.xxx.xxx.xxx.1723: S 3251573264:3251573264(0) win 8192 <mss 1410,nop,wscale 8,nop,nop,sackOK>
16:50:33.392743 IP 83.xxx.xxx.xxx.1723 > 80.xxx.xxx.xxx.49323: S 438699198:438699198(0) ack 3251573265 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 0>
16:50:34.903803 IP 80.xxx.xxx.xxx.49323 > 83.xxx.xxx.xxx.1723: . ack 1 win 66
16:50:35.165827 IP 80.xxx.xxx.xxx.49323 > 83.xxx.xxx.xxx.1723: P 1:157(156) ack 1 win 66: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) [|pptp]
16:50:35.165842 IP 83.xxx.xxx.xxx.1723 > 80.xxx.xxx.xxx.49323: . ack 157 win 5840
16:50:35.168996 IP 83.xxx.xxx.xxx.1723 > 80.xxx.xxx.xxx.49323: P 1:157(156) ack 157 win 5840: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) [|pptp]
16:50:35.803359 IP 80.xxx.xxx.xxx.49323 > 83.xxx.xxx.xxx.1723: P 157:325(168) ack 157 win 65: pptp CTRL_MSGTYPE=OCRQ CALL_ID(13970) CALL_SER_NUM(8) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) [|pptp]
16:50:35.822252 IP 83.xxx.xxx.xxx.1723 > 80.xxx.xxx.xxx.49323: P 157:189(32) ack 325 win 6432: pptp CTRL_MSGTYPE=OCRP CALL_ID(42752) PEER_CALL_ID(13970) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
16:50:35.939917 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 0 gre-ppp-payload
16:50:36.123767 IP 80.xxx.xxx.xxx.49323 > 83.xxx.xxx.xxx.1723: P 325:349(24) ack 189 win 65: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(42752) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
16:50:36.159750 IP 83.xxx.xxx.xxx.1723 > 80.xxx.xxx.xxx.49323: . ack 349 win 6432
16:50:38.949863 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 1 gre-ppp-payload
16:50:41.959861 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 2 gre-ppp-payload
16:50:44.969842 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 3 gre-ppp-payload
16:50:47.979859 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 4 gre-ppp-payload
16:50:50.989857 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 5 gre-ppp-payload
16:50:53.999834 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 6 gre-ppp-payload
16:50:57.009866 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 7 gre-ppp-payload
16:51:00.019849 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 8 gre-ppp-payload
16:51:03.029872 IP 83.xxx.xxx.xxx > 80.xxx.xxx.xxx: call 13970 seq 9 gre-ppp-payload
16:51:06.043761 IP 83.xxx.xxx.xxx.1723 > 80.xxx.xxx.xxx.49323: F 189:189(0) ack 349 win 6432
16:51:06.326186 IP 80.xxx.xxx.xxx.49323 > 83.xxx.xxx.xxx.1723: . ack 190 win 65


Zur Erläuterung: Die IP Adresse 83.xxx.xxx.xxx gehört zu Ihrem
VPN Server, die IP Adresse 80.xxx.xxx.xxx gehört zum Client.

Der Dump wurde direkt am Public-Interface Ihres VPN Servers
aufgenommen.

Im Dump sieht man, dass der Client um 16:50:33.392705
auf dem PPTP-Steuerkanal (Port 1723/TCP) eine Verbindung
inittiert. Über diesen Steuerkanal werden einige Pakete
ausgetauscht, bis dann der "PPP-Handshake" zum Aushandeln
der Verbindungsparameter beginnt.

Der PPP-Handshake erfolgt auf dem PPTP Datenkanal (IP
Protokoll 47, "GRE") und man sieht, wie ab 16:50:35.939917
der Server versucht, an den Client Datenpakete mit den
entsprechenden Verbindungsparametern zu senden. Allerdings
kommt vom Client kein einziges Paket zurück. Hier sollte
aber eigentlich ein Handshake stattfinden, mit Paketen, die
zwischen dem Client und dem Server ausgetauscht werden.

Nachdem der Server mehrere GRE Daten-Pakete an den Client gesendet
hat, ohne eine Antwort zu bekommen, schließt er um 16:51:06.043761
mit einem FIN Paket am Steuerkanal die Verbindung. Auf dieses Paket
antwortet der Client um 16:51:06.326186 mit einem ACK Paket, d.h.
die Steuerverbindung zum Client ist hier nach wie vor aufrecht!

Diesen Ablauf kann man auch schön im Logfile der VPN Servers
nachvollziehen (die Zeitstempel stimmen überein, beide Logs
wurden am selben Server aufgezeichnet):

Jun 17 16:50:35 router pptpd[22566]: CTRL: Client 80.xxx.xxx.xxx control connection started
Jun 17 16:50:35 router pptpd[22566]: CTRL: Starting call (launching pppd, opening GRE)
Jun 17 16:50:35 router pppd[22568]: Plugin radius.so loaded.
Jun 17 16:50:35 router pppd[22568]: RADIUS plugin initialized.
Jun 17 16:50:35 router pppd[22568]: pppd 2.4.2 started by root, uid 0
Jun 17 16:50:35 router pppd[22568]: using channel 11
Jun 17 16:50:35 router pppd[22568]: Using interface ppp1
Jun 17 16:50:35 router pppd[22568]: Connect: ppp1 <--> /dev/pty/s3
Jun 17 16:50:35 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:50:38 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:50:41 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:50:44 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:50:47 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:50:50 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:50:57 router last message repeated 2 times
Jun 17 16:51:00 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:51:03 router pppd[22568]: sent [LCP ConfReq id=0x1 <mru 1450> <asyncmap 0x0> <auth chap MS-v2> <magic 0xe0f521a4> <pcomp> <accomp>]
Jun 17 16:51:06 router pppd[22568]: LCP: timeout sending Config-Requests
Jun 17 16:51:06 router pppd[22568]: Connection terminated.
Jun 17 16:51:06 router pppd[22568]: Exit.


Nach meiner Erfahrung deuten diese Symptome darauf hin, dass
der Datenkanal blockiert ist, d.h. das Pakete mit IP Protokoll
47 (GRE) den Client nicht erreichen oder nicht gesendet werden
können. Üblicherweise liegt das an einer Firewall zwischen dem
Client und dem Internet, die diese Pakete blockiert.
Es könnte auch ein Router mit NAT-Funktion sein, durch den die
GRE Pakete blockiert werden.

Manche Internet-Provider sperren diese Pakete absichtlich je
nach verkauftem "Produkt" (d.h. Art des Internetzugangs)

Bitte prüfen Sie, ob Ihr UMTS Vertrag die Verwendung von PPTP
VPN, d.h. die Übertragung von IP Paketen mit Protokoll Nr. 47
unterstützt.

Eventuell kann auch der Helpdesk Ihres Providers mit diesen
technischen Details das Problem schnell identifizieren und beheben.

--------------


der helpdesk meines providers konnte das problem leider nicht "schnell identifizieren und beheben".
es koennte jedoch trotz allem an einer freischaltung dieses gre-protokolls liegen.

ein weiterer ansatz wuerde sich auf die die verschiedenen ms-chap versionen von win-xp und win-vista beziehen und muesste dann auch server-seitig geloest werden...


tja, das waers derweil mal wieder....

lg, joehittn

 

[Joehittn]

lol... problem geloest..


1) sim-karten-firewall ausschalten durch provider, dann wird der gre-kanal (kanal 47) durchgelassen...

2) domain-mitsenden einschalten, jedoch die domaene nicht mitsenden (feld leerlassen)... [da soll mal wer draufkommen #@§!!]


tjo, thats it, danke fuer die unterstuetzung, einen schoenen abend und ein schoenes spielchen heut abend!


lg, joehittn