1821 als PPTP VPN Router - Client?
Moderator: Lancom-Systems Moderatoren
1821 als PPTP VPN Router - Client?
Moin,
ich habe 5 Stück /24 Netze*, die ich nicht über IPSec sondern leider nur über PPTP erreichen kann. Die "VPN" Server stehen jeweils per fixe IP hinter einer Frontend Firewall im Netz und sind vom Arcor DSL- Addressbereich erreichbar und lassen eingehend nur 1723 zu. Die Verbindung wird nach 30 Sek. Inaktivität v. Server getrennt.
Der LC ist bei Arcor eingewählt. Ich würde gerne den LC eine Verbindung zum jeweiligen PPTP Server herstellen lassen und meine Clients NAT hinter der zugewiesenen IP der PPTP Gegenstelle verstecken. Es sollen nur Strecken aufgebaut werden, von der Gegenstelle wird keine Strecke zum 1821 aufgebaut. Es wird standard Windows CHAP2 geprüft und MPPE128 verschlüsselt, Netbios wird nicht übertragen. Der Client meldet sich nur per domäne\username und kennwort an**. ***
Kann der LC das? Lässt sich das überhaupt bewerkstelligen? (Bitte jetzt keine Sicherheitsbelehrung)
Ohne Assi verhaspele ich mich jedesmal. Meine Versuche sind bisher in die Hose gegangen. Kann mir jemand die Schritte erklären bzw. was gehört wohin? Wenn ja, wie kann ich die Verbindungen tracen bzw. kann man auch simple PPTP Verbindungen wie meine LC zu LC Verbindungen im Lanmonitor sehen oder werden die beim Syslog geschrieben? Kann ich per Trace im Telnet sehen, wenn da was schief läuft? Problem: Nach 1x Kennwort falsch/ falscher Verschlüsselung ist da leider erstmal für 5 Minuten Ruhe im Schacht.
Danke Euch
Liebe Grüße
Cheers,
Joe
*Erschwerend kommt hinzu, dass sich bei zwei Netzen der Addressbereich gleicht (192.168.0.0/24), ich möchte aber in Netz A eine andere Addresse erreichen als in Netz B. -> Kann aber erst mal vernachlässigt werden, da die beiden Addressen nicht allzu oft besucht werden.
** Kennwort ändert sich jede Woche, habe aber Kenntnis v. Kennwörtern 5 Wochen im Vorraus, kann man das per Script eintragen lassen?
*** Hinter einem Server erreiche ich ein Netz dahinter, dessen Gateway sich im int. Subnetz des Servers befindet. Wo kann ich die Routen eintragen? LC ist Standardgateway für Clients in meinem lokalen Netz.
ich habe 5 Stück /24 Netze*, die ich nicht über IPSec sondern leider nur über PPTP erreichen kann. Die "VPN" Server stehen jeweils per fixe IP hinter einer Frontend Firewall im Netz und sind vom Arcor DSL- Addressbereich erreichbar und lassen eingehend nur 1723 zu. Die Verbindung wird nach 30 Sek. Inaktivität v. Server getrennt.
Der LC ist bei Arcor eingewählt. Ich würde gerne den LC eine Verbindung zum jeweiligen PPTP Server herstellen lassen und meine Clients NAT hinter der zugewiesenen IP der PPTP Gegenstelle verstecken. Es sollen nur Strecken aufgebaut werden, von der Gegenstelle wird keine Strecke zum 1821 aufgebaut. Es wird standard Windows CHAP2 geprüft und MPPE128 verschlüsselt, Netbios wird nicht übertragen. Der Client meldet sich nur per domäne\username und kennwort an**. ***
Kann der LC das? Lässt sich das überhaupt bewerkstelligen? (Bitte jetzt keine Sicherheitsbelehrung)
Ohne Assi verhaspele ich mich jedesmal. Meine Versuche sind bisher in die Hose gegangen. Kann mir jemand die Schritte erklären bzw. was gehört wohin? Wenn ja, wie kann ich die Verbindungen tracen bzw. kann man auch simple PPTP Verbindungen wie meine LC zu LC Verbindungen im Lanmonitor sehen oder werden die beim Syslog geschrieben? Kann ich per Trace im Telnet sehen, wenn da was schief läuft? Problem: Nach 1x Kennwort falsch/ falscher Verschlüsselung ist da leider erstmal für 5 Minuten Ruhe im Schacht.
Danke Euch
Liebe Grüße
Cheers,
Joe
*Erschwerend kommt hinzu, dass sich bei zwei Netzen der Addressbereich gleicht (192.168.0.0/24), ich möchte aber in Netz A eine andere Addresse erreichen als in Netz B. -> Kann aber erst mal vernachlässigt werden, da die beiden Addressen nicht allzu oft besucht werden.
** Kennwort ändert sich jede Woche, habe aber Kenntnis v. Kennwörtern 5 Wochen im Vorraus, kann man das per Script eintragen lassen?
*** Hinter einem Server erreiche ich ein Netz dahinter, dessen Gateway sich im int. Subnetz des Servers befindet. Wo kann ich die Routen eintragen? LC ist Standardgateway für Clients in meinem lokalen Netz.
Cheers,
Joe
Joe
Hi joeMJ,
Über einen Eintrag in der PPTP-Liste (Kommunikation -> Protokolle -> PPTP-Liste) definierst du die Gegenstellen, z.B. FILIALE1 bis FILIALE5 und trägst dort die festen IP-Adressen der Server in diesen Filialen ein.
Dann trägst du in der PPP-Liste (Kommunikation -> Protokolle -> PPP-Liste) die notwendigen Parameter für die Gegenstellen FILIALE1 bis FILIALE5 ein. Wichtig sind dabei: Username, Passwort und Berechtigungen. Bei den Berechtigungen aktivierst du IP-Routing. Den Rest läßt du so wie er ist.
So, nun fehlen nur noch die Einträge in der IP-Routing-Tabelle mit dem du die Netz der jeweiliegen Filialen mit den Gegenstellen FILIALE1 bis FILIALE5 verknüpfst. In diesen Einträgen aktivierst du die Maskierung. Fertig...
Das Problem mit den gleichen Netzen nicht lösbar, da mußt du Wohl oder Übel für eines der beiden Netzte komplett neue Adressen vergeben.
Als allerletztes bleibt noch die Frage der Domain-Controller. Ist in jedem Netz ein eigener Controller, bei dem sich die User anmelden müßen oder steht bei dir ein einzelner Domain-Controller, bei dem die entfernten Netze die Authentizifierung der Clients prüfen?
Im ersten Fall du trägst die Domain-Controller im DNS-Server entweder fest ein oder du leitest die zugehörige DNS-Domain an den DNS-Servern der Filialen weiter, Das geht über TCP/IP -> DNS -> Weiterleitungen. Dort trägst du für *.domainx eine Weiterleitung zur Gegenstelle FILIALEx ein - ich gehe mal davon aus, daß bei der Einwahl ein DNS-Server zugewiesen wird.
Falls der Domain-Controller bei dir steht, dürfte das ganze vermutlich unmöglich sein. Aber vielleicht reicht es ja, wenn du den Port 445 per Portforwarding an den Domain-Controller weiterleitest. Sinnvoller wären jedoch unmaskierte Verbidnugen, dann fiele die ganze NAT-Problematik in sich zusammen.
Probier es am besten mal mit einer Filiale aus...
Gruß
Backslash
Der Rest geht releativ simpel - mit Ausnahme der gleichen Netze, doch dazu säter...Wie sieht est denn dann mit dem Rest meiner Wahnvorstellung aus? Für den Rest brauche ich keine Verschlüsselung...
Über einen Eintrag in der PPTP-Liste (Kommunikation -> Protokolle -> PPTP-Liste) definierst du die Gegenstellen, z.B. FILIALE1 bis FILIALE5 und trägst dort die festen IP-Adressen der Server in diesen Filialen ein.
Dann trägst du in der PPP-Liste (Kommunikation -> Protokolle -> PPP-Liste) die notwendigen Parameter für die Gegenstellen FILIALE1 bis FILIALE5 ein. Wichtig sind dabei: Username, Passwort und Berechtigungen. Bei den Berechtigungen aktivierst du IP-Routing. Den Rest läßt du so wie er ist.
So, nun fehlen nur noch die Einträge in der IP-Routing-Tabelle mit dem du die Netz der jeweiliegen Filialen mit den Gegenstellen FILIALE1 bis FILIALE5 verknüpfst. In diesen Einträgen aktivierst du die Maskierung. Fertig...
Das Problem mit den gleichen Netzen nicht lösbar, da mußt du Wohl oder Übel für eines der beiden Netzte komplett neue Adressen vergeben.
Als allerletztes bleibt noch die Frage der Domain-Controller. Ist in jedem Netz ein eigener Controller, bei dem sich die User anmelden müßen oder steht bei dir ein einzelner Domain-Controller, bei dem die entfernten Netze die Authentizifierung der Clients prüfen?
Im ersten Fall du trägst die Domain-Controller im DNS-Server entweder fest ein oder du leitest die zugehörige DNS-Domain an den DNS-Servern der Filialen weiter, Das geht über TCP/IP -> DNS -> Weiterleitungen. Dort trägst du für *.domainx eine Weiterleitung zur Gegenstelle FILIALEx ein - ich gehe mal davon aus, daß bei der Einwahl ein DNS-Server zugewiesen wird.
Falls der Domain-Controller bei dir steht, dürfte das ganze vermutlich unmöglich sein. Aber vielleicht reicht es ja, wenn du den Port 445 per Portforwarding an den Domain-Controller weiterleitest. Sinnvoller wären jedoch unmaskierte Verbidnugen, dann fiele die ganze NAT-Problematik in sich zusammen.
Probier es am besten mal mit einer Filiale aus...
Gruß
Backslash
Hallo Backslash,
danke Dir für Deine ausführliche Info. Ich denke mal so ist es auch absolut richtig. Allerdings komme ich in keiner Form durch.
Kann ich tracen (wenn ja wie) was da in die Hose geht? Der Admin auf der Gegenseite sagt, er könnte die Kiste (was immer da auch in Nürnberg steht) nicht managen bzw. nicht in die Logs schauen.
DNS wird zugewiesen, die Kiste macht laut ihm Auth / reicht weiter und lässt normales PPTP zu (sagt er) - IP Konfiguration wird richtig zugewiesen.
dickes Danke an Dich!
danke Dir für Deine ausführliche Info. Ich denke mal so ist es auch absolut richtig. Allerdings komme ich in keiner Form durch.

Kann ich tracen (wenn ja wie) was da in die Hose geht? Der Admin auf der Gegenseite sagt, er könnte die Kiste (was immer da auch in Nürnberg steht) nicht managen bzw. nicht in die Logs schauen.
DNS wird zugewiesen, die Kiste macht laut ihm Auth / reicht weiter und lässt normales PPTP zu (sagt er) - IP Konfiguration wird richtig zugewiesen.
dickes Danke an Dich!
Cheers,
Joe
Joe
Hi joeMJ,
Aber vermutlich scheitert es daran, daß die Gegenseite eine unverschlüsselte PPTP-Verbindung ablehnt...
Gruß
Backslash
ja du kannst als erstes einen PPP-Trace einschalten (im telnet trace + ppp), um zu schauen ob die PPTP-Verbindung überhaupt aufgebaut wird.Kann ich tracen (wenn ja wie) was da in die Hose geht? Der Admin auf der Gegenseite sagt, er könnte die Kiste (was immer da auch in Nürnberg steht) nicht managen bzw. nicht in die Logs schauen
Aber vermutlich scheitert es daran, daß die Gegenseite eine unverschlüsselte PPTP-Verbindung ablehnt...
Gruß
Backslash
Nehme an, Du hast Recht:
Offensichtlich - Syn geht - Ack kommt nicht zurück.
Inzwischen bin ich schlauer - sind alles Windows RAS Server, die offensichtlich doch "auch" L2TP zulassen.
Allerdings hab' ich erst mal keine Kenntnis über Windows RAS L2TP, da bis jetzt noch nie genutzt (Lancom hat mir den Mist immer abgenommen). Ich nehme fast an, dass meine Bemühungen aussichtslos sind, oder ich stelle mir 'ne ISA hier hin. 
Code: Alles auswählen
[PPP] 2005/12/09 15:59:43,510
PPTP call control: ack missing for packet # 23 of call id 47447 - correct acknow
ledged sequence number
[PPP] 2005/12/09 15:59:43,510
Positive Restart-Timeout event for LCP
Generating LCP configure-request for peer NC1552
Inserting local MRU 1460
Inserting local authentication protocol PAP
Inserting local magic number f4685821
Inserting local option protocol field compression
Inserting local option address- and controlfield compression
Sending LCP configure-request with ID 17 and length 22 to peer NC1552 (channel 0)
Starting LCP restart timer with 3000 milliseconds
[PPP] 2005/12/09 15:59:45,970
PPTP call control: connect timeout for call id 47447
[PPP] 2005/12/09 15:59:45,970
PPTP: Error: PPTP-no-response (0x0116) for NC1552 (x.x.x.x)
[PPP] 2005/12/09 15:59:45,970
PPTP control channel: closing TCP connection
Inzwischen bin ich schlauer - sind alles Windows RAS Server, die offensichtlich doch "auch" L2TP zulassen.



Cheers,
Joe
Joe
Hi joeMJ,
Es kann aber auch sein, daß der Server nicht damit zurecht kommt, daß du von ihm eine Authentifizierung forderst:
Stelle mal bei der Gegenstelle in der PPP-Liste "Keine Überprüfung durchführen" ein - so wie es auch als Default vorgegeben ist.
M$ ist zuzutrauen, daß sie völlig durcheinander geraten, wenn bei einkommenden Rufen eine Authentifizierung von ihnen gefordert wird...
Gruß
Backslash
Das sieht eher danach aus, als ob die Firewall vor dem Server nicht mit PPTP umgehen kann und die GRE-Pakete nicht durchläßt - es kommt ja überhaupt keine Antwort...Offensichtlich - Syn geht - Ack kommt nicht zurück.
Es kann aber auch sein, daß der Server nicht damit zurecht kommt, daß du von ihm eine Authentifizierung forderst:
Code: Alles auswählen
Inserting local authentication protocol PAP
M$ ist zuzutrauen, daß sie völlig durcheinander geraten, wenn bei einkommenden Rufen eine Authentifizierung von ihnen gefordert wird...
Wenn obiges nicht hilft, hast du vermutlich recht...Ich nehme fast an, dass meine Bemühungen aussichtslos sind, oder ich stelle mir 'ne ISA hier hin.
Gruß
Backslash
Kehrtwendung
ist mir schon fast peinlich - vorweg:
nix niente nada. Und wenn ich auf der Gegenseite noch nicht mal in's Log schauen kann, ist's eigentlich schon fast aussichtslos - oder?
- hatte unterwegs auf der nach hause Reise probiert - vom PocketPC aus - auch der eigentliche Grund - da könnte ich dann per TSC schön Wartung machen.
Jetzt könnte ich übrigens gleich platzen: In einer der letzten beiden Emails, die ich vom Dienstleister bekommen habe, kriege ich folgende Antwort: Ja, wir nutzen in Nürnberg bei Ihren 3 Knoten ISA2004.
Ich könnte !"§%&§!/"& schreien vor Wut! Soviel zu meiner Gemütslage.
Bevor Du mich lynchst: Welcher der folgenden wäre am sinnvollsten:

Werde dann wohl erst am Montag das auf die Reihe bekommen, da ich dann erst da wieder Support bekomme.
1000x Danke für Deine Hilfe!
ist mir schon fast peinlich - vorweg:
Hatte ja gerade die anderen auch durchprobiert - es kommt einfach nix zurückStelle mal bei der Gegenstelle in der PPP-Liste "Keine Überprüfung durchführen" ein - so wie es auch als Default vorgegeben ist

- hatte unterwegs auf der nach hause Reise probiert - vom PocketPC aus - auch der eigentliche Grund - da könnte ich dann per TSC schön Wartung machen.
Jetzt könnte ich übrigens gleich platzen: In einer der letzten beiden Emails, die ich vom Dienstleister bekommen habe, kriege ich folgende Antwort: Ja, wir nutzen in Nürnberg bei Ihren 3 Knoten ISA2004.

Ich könnte !"§%&§!/"& schreien vor Wut! Soviel zu meiner Gemütslage.
Bevor Du mich lynchst: Welcher der folgenden wäre am sinnvollsten:
Werde dann wohl erst am Montag das auf die Reihe bekommen, da ich dann erst da wieder Support bekomme.
1000x Danke für Deine Hilfe!
Cheers,
Joe
Joe
Hi joeMJ
Gruß
Backslash
dann scheit irgendwo zischen dem LANCOM und dem Server tatsächlich noch eine weitere Firewall zu sein, die die GRE-Pakete herausfiltert...Hatte ja gerade die anderen auch durchprobiert - es kommt einfach nix zurück nix niente nada.
Ein Blick in die Logs der Gegeseite wäre ggf. hilfreich - wenn aber die GRE-Pakete schon gefiltert werden, dann werden sie dier auch nur zeigen, daß die PPP-Verhandlung nicht läuft...Und wenn ich auf der Gegenseite noch nicht mal in's Log schauen kann, ist's eigentlich schon fast aussichtslos - oder?
Da das LANCOM MSCHAPv2 als Authentifizierungsmethode beherrscht, sollte diese auch verwendet werden. Wichtig ist auf Serverseite die erzwungene Verschlüsselung zu deaktivieren - frag mich aber bitte nicht, wo das einstellbar ist...Bevor Du mich lynchst: Welcher der folgenden wäre am sinnvollsten
Gruß
Backslash
Danke Dir für Deine Tipps!
-> Rückmeldung aus Nürnberg - O-Ton: "Ja, mit GRE haben wir unsere Probleme. Sie sind bei uns aufgelaufen." Ich nehme mal an, das ist das generelle Problem.
Ich habe heute um 14:00 'ne Supportstunde bei Netcologne. Unter anderem testen wir auch unsere Firewalls. Danach kann ich kurz testen, ob wir das hier mit unserer alten ISA vernünftig hinbekommen. Das kann ich ja dann auf unsere anderen 5 Netze adaptieren. Wäre überhaupt wesentlich sinnvoller, den Außendienstler- Jungs eine Lancom- Kiste zuhause hinzustellen.
Werde es zunächst mit L2TP und drumrum mit IPSEC versuchen - wenn es klappt. Wenn nicht, werde ich es so von oben bis unten versuchen. Die ISA hab' ich jetzt gottseidank hier vor der Nase.
-> Rückmeldung aus Nürnberg - O-Ton: "Ja, mit GRE haben wir unsere Probleme. Sie sind bei uns aufgelaufen." Ich nehme mal an, das ist das generelle Problem.
Ich habe heute um 14:00 'ne Supportstunde bei Netcologne. Unter anderem testen wir auch unsere Firewalls. Danach kann ich kurz testen, ob wir das hier mit unserer alten ISA vernünftig hinbekommen. Das kann ich ja dann auf unsere anderen 5 Netze adaptieren. Wäre überhaupt wesentlich sinnvoller, den Außendienstler- Jungs eine Lancom- Kiste zuhause hinzustellen.
Werde es zunächst mit L2TP und drumrum mit IPSEC versuchen - wenn es klappt. Wenn nicht, werde ich es so von oben bis unten versuchen. Die ISA hab' ich jetzt gottseidank hier vor der Nase.
Cheers,
Joe
Joe
Rückmeldung/ Test gg. ISA
Moin 
warum's in Nürnberg nicht geklappt hat?
Keine Ahnung. Jetzt schon. Bin so - ein "mini" Stückchen weiter. Zunächst hat auch bei uns GRE geklemmt, hat der Supporter allerdings sofort gesehen und korrigiert.
Nürnberg funktioniert jetzt mit PPTP, allerdings nicht mit MSCHAPV2 sondern nur mit MSCHAP (warum? Habe ihm gesagt, was er von mir zulassen soll). Damit ist die Thematik Nürnberg vorerst erledigt.
Lancom VPN mit PSK gg. ISA2004
Problem ist hier, dass ISA2004 hinter einer weiteren FW steht. Ziel war "Lancom dynamic VPN" mit PSK. No chance, es kam immer zum Abbruch. Aussage Firewalltechniker: "Macht der alles (komplettes Handshake) über ICMP?" - haben wir zugelassen und nach ISA geschickt, sind allerdings auch kein Stück weiter - nehme an es klemmt an der Frontend Firewall. Gut wäre ein Tutorial, Lancom gg. ISA2004 mit der bestmöglichsten Verschlüsselung - nicht gefunden bin ich zu blind?
Antwort v. Trace:
Lancom PPTP gg. ISA2004 mit erzwungenem MSCHAPv2 Versuch, macht mich aber auch nicht glücklich, da ich bei
Auf die Nase falle. Wäre aber v. Verschlüsselungstype (falls MSCHAPV2 doch klappt) in Ordnung, da hier nur SSL Verbindungen drüber laufen. Kann ich das irgendwie hinbekommen?
Die KB bei Lancom ist in Punkto ISA2004 leider nicht sehr hilfreich.
Soviel zum Stand der Dinge
Immerhin kriegen wir jetzt "MSCHAP" hin. Optimum wäre natürlich irgendwie eine vernünftige Verschlüsselung. Liegt hier ein Verständnisproblem v. Lancom VPN vor? Gegen alle anderen dem 1821 bekannten LC's klappt's ja auch ohne Probleme
Nur der doofe ISA will nich.

warum's in Nürnberg nicht geklappt hat?
Keine Ahnung. Jetzt schon. Bin so - ein "mini" Stückchen weiter. Zunächst hat auch bei uns GRE geklemmt, hat der Supporter allerdings sofort gesehen und korrigiert.
Nürnberg funktioniert jetzt mit PPTP, allerdings nicht mit MSCHAPV2 sondern nur mit MSCHAP (warum? Habe ihm gesagt, was er von mir zulassen soll). Damit ist die Thematik Nürnberg vorerst erledigt.
Lancom VPN mit PSK gg. ISA2004
Problem ist hier, dass ISA2004 hinter einer weiteren FW steht. Ziel war "Lancom dynamic VPN" mit PSK. No chance, es kam immer zum Abbruch. Aussage Firewalltechniker: "Macht der alles (komplettes Handshake) über ICMP?" - haben wir zugelassen und nach ISA geschickt, sind allerdings auch kein Stück weiter - nehme an es klemmt an der Frontend Firewall. Gut wäre ein Tutorial, Lancom gg. ISA2004 mit der bestmöglichsten Verschlüsselung - nicht gefunden bin ich zu blind?
Antwort v. Trace:
Code: Alles auswählen
[VPN-Status] 2005/12/14 16:16:18,860
VPN: connecting to GG0 (xxx.xxx.xxx.xxx)
[VPN-Status] 2005/12/14 16:16:18,870
VPN: start dynamic VPN negotiation for GG0 (xxx.xxx.xxx.xxx) via ICMP/U
DP
[VPN-Status] 2005/12/14 16:16:18,870
VPN: create dynamic VPN V2 authentication packet for GG0 (xxx.xxx.xxx.xxx)
DNS: 192.168.10.1, 0.0.0.0
NBNS: 0.0.0.0, 0.0.0.0
polling address: 192.168.10.1
[VPN-Status] 2005/12/14 16:16:28,870
VPN: fallback to dynamic VPN V1 for GG0 (xxx.xxx.xxx.xxx)
[VPN-Status] 2005/12/14 16:16:28,870
VPN: create dynamic VPN V1 authentication packet for GG0 (xxx.xxx.xxx.xxx)
DNS: 192.168.10.1, 0.0.0.0
NBNS: 0.0.0.0, 0.0.0.0
[PPP] 2005/12/14 16:16:32,180
LCP polling timeout for peer AR-PIPE - echo-response received during last interv
al
Sending LCP echo-request with ID 47 and length 8 to peer AR-PIPE (channel 1)
[PPP] 2005/12/14 16:16:32,180
Received LCP frame from peer AR-PIPE (channel 1)
LCP echo-response with ID 47 and length 10 to peer AR-PIPE
[VPN-Status] 2005/12/14 16:16:48,870
VPN: connection for GG0 (xxx.xxx.xxx.xxx) timed out: no response
[VPN-Status] 2005/12/14 16:16:48,880
VPN: Error: IFC-I-Connection-timeout-dynamic (0x1105) for GG0 (xxx.xxx.xxx.xxx)
[VPN-Status] 2005/12/14 16:16:48,900
VPN: selecting next remote gateway using strategy eFirst for GG0
=> no remote gateway selected
[VPN-Status] 2005/12/14 16:16:48,900
VPN: selecting first remote gateway using strategy eFirst for GG0
=> CurrIdx=0, IpStr=>xxx.xxx.xxx.xxx<, IpAddr=xxx.xxx.xxx.xxx, IpTtl=0s
[VPN-Status] 2005/12/14 16:16:48,900
VPN: installing ruleset for GG0 (xxx.xxx.xxx.xxx)
[VPN-Status] 2005/12/14 16:16:48,900
VPN: GG0 (xxx.xxx.xxx.xxx) disconnected
[VPN-Status] 2005/12/14 16:16:48,920
VPN: rulesets installed
Lancom PPTP gg. ISA2004 mit erzwungenem MSCHAPv2 Versuch, macht mich aber auch nicht glücklich, da ich bei
Code: Alles auswählen
[PPP] 2005/12/14 15:53:57,650
PPTP call control: ack missing for packet # 16 of call id 53543 - correct acknow
ledged sequence number
[PPP] 2005/12/14 15:53:57,650
Positive Restart-Timeout event for LCP
Generating LCP configure-request for peer GG0
Inserting local MRU 1460
Inserting local magic number 25e32bcc
Inserting local option protocol field compression
Inserting local option address- and controlfield compression
Sending LCP configure-request with ID 10 and length 18 to peer GG0 (channel 0)
Starting LCP restart timer with 3000 milliseconds
[PPP] 2005/12/14 15:54:00,260
PPTP call control: connect timeout for call id 53543
[PPP] 2005/12/14 15:54:00,260
PPTP: Error: PPTP-no-response (0x0116) for GG0 (xxx.xxx.xxx.xxx)
[PPP] 2005/12/14 15:54:00,260
PPTP control channel: closing TCP connection
[PPP] 2005/12/14 15:54:00,270
PPTP call control: call destroyed
[PPP] 2005/12/14 15:54:00,280
PPTP control channel: TCP connection closed
PPTP control channel: TCP job destroyed
Die KB bei Lancom ist in Punkto ISA2004 leider nicht sehr hilfreich.
Soviel zum Stand der Dinge


Cheers,
Joe
Joe