Einzelnen WLAN Client über PPTP VPN routen

[Popasi]

Hallo LANCOM User,

aktuell betriebe ich 5-10 Clients an meinem LANCOM 1821 über LAN und WLAN (zwei SSIDs wegen verschiedener Verschlüsselung), aber in einem Netz (192.168.1.x). Der LANCOM ist über T-COM DSL ans Internet angebunden, alle Clients haben gleichberechtigten Zugang zum Internet.

Ich möchte nun folgende Änderung einführen :

Ein bestimmter Client, der über WLAN angebunden ist, soll ausschließlich über eine neue VPN PPTP Verbindung, die über die bestehende DSL Verbindung laufen soll, geroutet werden. Da es sich nicht um einen Windows/Linux Client handelt, bei dem ich einen VPN Client installieren könnte, müßte das Routing und der VPN Verbindungsaufbau auf jeden Fall vom LANCOM1821 gemacht werden. Das Tunneling soll/muss für diesen Client transparent sein. Der Client sollte nach der Änderung immer noch hinter der LANCOM Firewall sein.

Mir schwirren so verschiedene Ideen durch den Kopf, sowas wie VLAN, neue SSID etc. Ich las hier im Forum, das der LANCOM 1821 keine verschlüsselte PPTP Verbindung aufbauen kann, ist das noch korrekt ?
Der besagte Client könnte problemlos auch in einem eigenen logischen Netz sein, da ein Zugriff auf die anderen Clients (und umgekehrt) nicht notwendig ist, nur der Zugriff über den Router ins Internet, dann über den VPN Tunnel.

Hat jemand einen Vorschlag ? Vielleicht hat jemand eine Idee, wie ich es möglichst einfach realisieren kann, wenn es überhaupt möglich ist

Danke und viele Grüße !

[backslash]

Hi Popasi

Ich las hier im Forum, das der LANCOM 1821 keine verschlüsselte PPTP Verbindung aufbauen kann, ist das noch korrekt ?

das ist korrekt

Hat jemand einen Vorschlag ? Vielleicht hat jemand eine Idee, wie ich es möglichst einfach realisieren kann, wenn es überhaupt möglich is

Das Stichwort heißt hier: "Policy based Routing", d.h. du erstellst eine Firewallregel, die alles, was der Client sendet, mit einem Routing-Tag versieht und trägst in der Routing-Tabelle eine entsprechend getaggte Route ein...

Gruß
Backslash

[Popasi]

Hallo backslash,

danke für die Antwort.

Folgendes habe ich also probiert :

- Unter Communication/PPTP List eine PPTP Gegenstelle angelegt, mit IP Adresse, da Namensauflösung nicht funktioniert (!?)
- Unter Communication/PPP List für die PPTP Gegenstelle die Login Daten hinterlegt, IP Routing aktiviert (was anderes brauche ich nicht...)
- Unter IP-Router/Routing/Routing Table habe ich einen Eintrag für Routing Tag 69 eingetragen, kopiert vom letzten Eintrag (T-ONLINE Default Route) (255.255.255.255)
- Unter Firewall/QoS/Rules/Rules habe ich eine neue Regel erstellt, die für eine bestimmte IP Adresse das Routing Tag 69 hat, ansonsten aber als Action "Transfer" hat.

Funktionieren tut es leider nicht, nach "tr # ppp" beim Router erhalte ich nun bei jedem Request vom besagten Client ein :

PPTP control channel: config loop detected, for <REMOTE_SITE_NAME>

Was habe ich falsch gemacht ?

Danke und viele Grüße !

[backslash]

Hi Popasi

PPTP control channel: config loop detected, for <REMOTE_SITE_NAME>

das passiert, wenn die Adresse, über die der PPTP-Endpunkt erreicht wird, nur über die PPTP-Verbindung selbst erreichbar ist. Ich hoffe, du hast hier:

Unter Communication/PPTP List eine PPTP Gegenstelle angelegt, mit IP Adresse

*NICHT* auch das Routing-Tag 69 eingetragen. Hier muß natürlich das Tag 0 hin.


Gruß
Backslash

[Popasi]

Super, jetzt komme ich einen entscheidenden Schritt weiter, leider klappt es nicht nicht ganz. Es wird leider noch keine Verbindung aufgebaut, hier das "tr # ppp" Log :

Code: Alles auswählen

[PPP] 2007/05/07 18:30:09,150
PPTP control channel: connecting to <IP ADDRESS>


[PPP] 2007/05/07 18:30:09,150
PPTP control channel: waiting for TCP connect
PPTP control channel: use local port: 13153


[PPP] 2007/05/07 18:30:09,300
PPTP control channel: TCP connection established
PPTP control channel: StartControlConnectionRequest sent


[PPP] 2007/05/07 18:30:09,460
PPTP control channel: received StartControlConnectionReply
PPTP call control: OutgoingCallRequest sent for call id 26772


[PPP] 2007/05/07 18:30:10,320
PPTP dispatcher: received GRE packet for call id 26772 in call state CALL - packet dropped


[PPP] 2007/05/07 18:30:10,320
Change phase to ESTABLISH
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds


[PPP] 2007/05/07 18:30:10,320
PPTP call control: received OutgoingCallReply for call id 26772: peer call id 54912
PPTP call control: SetLinkInfo sent for call id 26772 with SendACCM=0x00000000 and ReceiveACCM=0x00000000
PPTP call control: set remote window to 32 for <REMOTE_SITE>
PPTP call control: connect request for PPP sent


[PPP] 2007/05/07 18:30:10,520
Positive Restart-Timeout event for LCP
Stop waiting for connection
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer <REMOTE_SITE>
Inserting local MRU 1460
Inserting local magic number 93a1b090
Sending LCP configure-request with ID 00 and length 14 to peer <REMOTE_SITE> (channel 0)
Starting LCP restart timer with 3000 milliseconds


[PPP] 2007/05/07 18:30:10,690

Received LCP frame from peer <REMOTE_SITE> (channel 0)
Evaluate configure-ack with ID 00 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds


[PPP] 2007/05/07 18:30:10,830

LCP polling timeout for peer T-ONLINE - echo-response received during last interval
Sending LCP echo-request with ID 3b and length 8 to peer T-ONLINE (channel 1)


[PPP] 2007/05/07 18:30:10,840

Received LCP frame from peer T-ONLINE (channel 1)

LCP echo-response with ID 3b and length 10 to peer T-ONLINE


[PPP] 2007/05/07 18:30:13,320

Received LCP frame from peer <REMOTE_SITE> (channel 0)
Evaluate configure-request with ID 01 and size 29
Peer MRU 1408 accepted
Peer ACCM 00000000000000000000000000000000, accepted
Peer requests authentication protocol c223, NAK with CHAP MD5
Peer magic number 7c34de1f accepted
Peer requests protocol field compression, rejected
Peer requests address- and controlfield compression, rejected
Negative Configure-Request-Received event for LCP
Sending LCP configure-reject with ID 01 and length 8 to peer <REMOTE_SITE> (channel 0)


[PPP] 2007/05/07 18:30:13,520
Positive Restart-Timeout event for LCP
Generating LCP configure-request for peer <REMOTE_SITE>
Inserting local MRU 1460
Inserting local magic number 93a1b090
Sending LCP configure-request with ID 02 and length 14 to peer <REMOTE_SITE> (channel 0)
Starting LCP restart timer with 3000 milliseconds


[PPP] 2007/05/07 18:30:13,660

Received LCP frame from peer <REMOTE_SITE> (channel 0)
Evaluate configure-request with ID 02 and size 25
Peer MRU 1408 accepted
Peer ACCM 00000000000000000000000000000000, accepted
Peer requests authentication protocol c223, NAK with CHAP MD5
Peer magic number 7c34de1f accepted
Negative Configure-Request-Received event for LCP
Sending LCP configure-nak with ID 02 and length 9 to peer <REMOTE_SITE> (channel 0)


[PPP] 2007/05/07 18:30:13,660

Received LCP frame from peer <REMOTE_SITE> (channel 0)
Evaluate configure-ack with ID 02 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds


[PPP] 2007/05/07 18:30:13,800

Received LCP frame from peer <REMOTE_SITE> (channel 0)
Evaluate configure-request with ID 03 and size 20
Peer MRU 1408 accepted
Peer ACCM 00000000000000000000000000000000, accepted
Peer magic number 7c34de1f accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 03 and length 20 to peer <REMOTE_SITE> (channel 0)
Stopping LCP restart timer
This-Layer-Up action for LCP
Change phase to AUTHENTICATE
This-Layer-Up action for LCP
Change phase to CALLBACK
This-Layer-Up action for LCP
Change phase to NETWORK
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer <REMOTE_SITE>
Inserting IP address 0.0.0.0
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 22 to peer <REMOTE_SITE> (channel 0)
Starting IPCP restart timer with 3000 milliseconds


[PPP] 2007/05/07 18:30:13,970

Received LCP frame from peer <REMOTE_SITE> (channel 0)
Terminate-Request-Received event for LCP


[PPP] 2007/05/07 18:30:13,970
This-Layer-Down action for LCP
Lower-Layer-Down event for BACP
Stopping BACP restart timer
Lower-Layer-Down event for CCP
Stopping CCP restart timer
Lower-Layer-Down event for IPCP
Stopping IPCP restart timer
Lower-Layer-Down event for IPXCP
Stopping IPXCP restart timer
Resetting LCP restart timer with 3000 milliseconds
Change phase to TERMINATE
Sending LCP terminate-request with ID 05 and length 4 to peer <REMOTE_SITE> (channel 0)
Starting LCP restart timer with 3000 milliseconds
Sending LCP terminate-ack with ID 00 and length 4 to peer <REMOTE_SITE> (channel 0)


[PPP] 2007/05/07 18:30:13,970
Change phase to DEAD
Stopping LCP restart timer
Stopping IPXCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer


[PPP] 2007/05/07 18:30:13,980
PPTP: Disconnect info: remote-disconnected (0x4301) for <REMOTE_SITE> (66.150.105.18)

[PPP] 2007/05/07 18:30:14,010
PPTP call control: call destroyed


[PPP] 2007/05/07 18:30:14,010
PPTP control channel: closing TCP connection


[PPP] 2007/05/07 18:30:14,010
PPTP control channel: TCP connection closed
PPTP control channel: TCP job destroyed


[PPP] 2007/05/07 18:30:14,110
PPTP dispatcher: received GRE packet for unknown call id 26772 - packet dropped

Warum geht der Verbindungaufbau schief, 0.0.0.0 ist nicht wirklich die sinnvolle IP Adresse ?

[backslash]

Hi Popasi

Warum geht der Verbindungaufbau schief, 0.0.0.0 ist nicht wirklich die sinnvolle IP Adresse ?

das LANCOM fordert 0.0.0.0, weil die Verbindung maskiert ist und die Gegenseite eine Adresse zuweisen soll. Aber genau das will die Gegenseite nicht und sendet den "Terminate-Request".

Jetzt mußt du auf der Gegenseite schauen, warum diese die Verbindung nicht annehmen will... Ein möglicher Grund wäre eine fehlender Adresspool

Gruß
Backslash

[Popasi]

Mh, schlecht, auf die Gegenseite habe ich keinen Einfluss, ist ein VPN Zugang in Amerika. Mit Windows funktioniert der Zugang problemlos, wenn ich dort eine VPN PPTP Verbindung einrichte, IP Adresse inklusive, die wird automatisch zugewiesen. Gibt es nichts, was ich vom LANCOM aus noch machen kann ?

[backslash]

Hi Popasi

Mh, schlecht, auf die Gegenseite habe ich keinen Einfluss, ist ein VPN Zugang in Amerika.

das ist schlecht...

Mit Windows funktioniert der Zugang problemlos, wenn ich dort eine VPN PPTP Verbindung einrichte, IP Adresse inklusive, die wird automatisch zugewiesen

Das LANCOM fordert ja auch die Zuweisung einer Adresse - das Windows macht das nicht anders - schau es dir mal mit Wireshark an...

Es könnte auch sein, daß die Gegenseite die Verbindung ablehnt, weil keine Verschlüsselung ausgehandelt wurde. Dann hast du generell "verloren"...

Gibt es nichts, was ich vom LANCOM aus noch machen kann ?

nun ja: kein PPTP verwenden - weil es unverschlüsselt ist - und auf IPSec umsteigen. Hier im Forum gibt es eine schöne Anleitung vor Jirka, wie man das Windows-IPSec mit dem LANCOM koppelt...


Gruß
Backslash

[Popasi]

Es könnte auch sein, daß die Gegenseite die Verbindung ablehnt, weil keine Verschlüsselung ausgehandelt wurde. Dann hast du generell "verloren"...

So sieht es aus, habe es eben mal unter Windows mit explizit ausgeschalter Verschlüsselung probiert, dann klappt es ebenfalls nicht....nun gut, ich nehme nicht an, das es mit der LCOS 7.x Version PPTP mit Verschlüsselung geben wird....kann ich diesen also abschreiben.

Vielen Dank für die Infos !

[ittk]

Hi Popasi,

lies zum thema PPTP und MPPE folgenden Thread:

http://www.lancom-forum.de/topic,5128,- ... lient.html

damit sollten dann alle deine Fragen beantwortet sein.

[Popasi]

Ah, danke für den Link, ittk. Die Meinungen sind klar und ich kann alle Seiten verstehen, auch wenn ich es natürlich für mich als (Privat-)Anwender schade finde, das die verschlüsselte PPTP Verbindungsmöglichkeit nicht implementiert ist. Die Gründe und das Argument mit dem Firmeneinsatz kann ich verstehen.

Ist übrigens das zweite Mal, das ich dieses Argument bei einem fehlenden Feature hier gelesen habe, das erste Mal war die Diskussion über die nicht implementierten WLAN Features des Atheros Chipsatz (Super-AG als Stichwort). Da in Firmen hauptsächlich Notebooks mit Centrino Chipsätze eingesetzt werden, ist das nicht implementiert, mangels Nachfrage. Gerade das dynamische Channel Bonding fehlt mir sehr.

So ist das, wenn man einen Router kauft, der für Firmenkunden vorgesehen ist. Das nächste Mal werde ich meine Kaufentscheidung nochmal diesbezüglich überdenken, ich denke das wird bei Verfügbarkeit von echten WLAN n-Standard Geräten der Fall sein.