VPN Verbindung mit Windowsbordmittel gelingt nicht.

[scatty]

Hi,

Ich habe Lancom und Windows XP nach folgendem Artikel konfiguriert.
http://www.lancom-forum.de/lhtopic,1507,0,0,asc,.html
Leider scheint mein Windows keinerlei Aktivität zu zeigen sobald ich einen Ping auf die IP Adresse im lokalen Netzwerk meines Ziel LAN's mache. Angeblich soll da ja was erscheinen von wegen wird ausgehandelt, etc. Bei mir gibts allerdings nur timeouts.

kann mir da irgendjemand weiterhelfen?

Danke
Jan

[ittk]

Hi,

warum machst du es dir so kompliziert. Da verweise ich doch einfach mal auf diesen Thread:

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

Ferner koenntest du auch noch den LANCOM Standard VPN Client benutzen.

Aber ich kann dir wirklich aus Sicherheits- und Funktionalen Aspekten nur den ADV-VPN Client ans Herz legen.

[eddia]

Hallo Jan,

Leider scheint mein Windows keinerlei Aktivität zu zeigen sobald ich einen Ping auf die IP Adresse im lokalen Netzwerk meines Ziel LAN's mache. Angeblich soll da ja was erscheinen von wegen wird ausgehandelt, etc. Bei mir gibts allerdings nur timeouts.

dann stimmt mit hoher Wahrscheinlichkeit die IP-Adresse des pings nicht mit dem konfigurierten Netzwerk unter rightsubnet in der ipsec.conf überein.

Gruß

Mario

[eddia]

Hallo ittk,

warum machst du es dir so kompliziert. Da verweise ich doch einfach mal auf diesen Thread:

ja - der ist schon nicht schlecht für den Anfang. Unterstützt nur leider keine zertifikatsbasierende Authentifizierung per Smartcard; aber man kann ja für kostenlos nicht alles haben...

Aber ich kann dir wirklich aus Sicherheits- und Funktionalen Aspekten nur den ADV-VPN Client ans Herz legen.

...aber selbst beim kostenpflichtigen ADV-Client sieht das nicht viel besser aus. Es sind nur ein paar Smartcards direkt ansprechbar bzw. weitere per PKCS.11 einbindbar. Dass der Standard unter Windows CSP heisst, hat Lancom (naja in diesem Fall eigentlich NCP) wohl verschlafen.

Gruß

Mario

[scatty]

dann stimmt mit hoher Wahrscheinlichkeit die IP-Adresse des pings nicht mit dem konfigurierten Netzwerk unter rightsubnet in der ipsec.conf überein.

leider schon.

so schaut meine ipsec.conf aus:

conn TEST
left=%any
right=xxx.xxx.xxx.xxx
rightsubnet=10.10.10.246
rightca="CN=VPN"
network=auto
auto=start
pfs=yes

habe auch schon mit rightsubnet=10.10.10.0/24 versucht. leider ohne selbigen erfolg. Ping erfolgt übrigens auf 10.10.10.246, also sollte es doch funktionieren.

Ich habe mit zertifikaten gearbeitet und hatte gehofft, das so auch hinzubekommen.
gibt es irgendwelche möglichkeiten zu sehen ob irgendetwas geschieht? irgendwelche tracetools?

danke
Jan

[eddia]

Hallo Jan,

so schaut meine ipsec.conf aus:

conn TEST
left=%any
right=xxx.xxx.xxx.xxx
rightsubnet=10.10.10.24

dass dies ohne Angabe einer Netzmaske ziemlich sinnlos ist, ist Dir klar?

habe auch schon mit rightsubnet=10.10.10.0/24 versucht. leider ohne selbigen erfolg. Ping erfolgt übrigens auf 10.10.10.246, also sollte es doch funktionieren.

Das sollte es. Falls Du jedoch Konfigurationsänderungen vornimmst, musst Du danach mit "ipsec -delete" und danach mit "ipsec" die Windows IPSec-Regeln erneuern.

Gruß

Mario

[scatty]

Mhhh, also den befehl mit delete kannte ich auch schon und hab ihn fleissig verwendet. noch irgend ne andere idee?

danke
Jan

[scatty]

könnte es noch an irgendwelchen fehlkonfigurationen am lancom liegen? oder würde er mir dann irgendwas anderes sagen als timeout?

und noch ein punkt. ich bin hier in einem netzwerk mit localer ip adresse 10.10.68.90 also schon recht ähnlich. könnte es deswegen probleme geben?

und ich muss hier in dem netzwerk zunächst ne windows vpn verbindung aufbauen. könnte das zu konflikten führen?

ansonsten weiss ich langsam nicht mehr weiter

[scatty]

so, bin mal wieder ein stückchen weiter. Das ereignisprotokoll von windows hat mir verraten, dass er probleme mit dem IPSec dienst hat. Jetzt funktioniert das einwandfrei, nur bleibt er auf ewig bei Ip-sicherheit wird verhandelt hängen.

kann ich irgendwie analysieren wo nun das problem hängt?
gibts da ne trace möglichkeit?

danke
Jan

[scatty]

So, nun habe ich auch einen entsprechenden fehler im lancom sichten können.

Connection to VPN - No rule matched IDs - unknown connection or incorrect ID (e.g. IP network definition)(Responder, IPSec)[0x3201]

Sieht so aus, als ob irgendwelche Identitäten falsch angegeben sind, oder?
Bin mir aber eigentlich zimlich sicher, dass die schon richtig sein sollten...werde da noch etwas rumprobieren. falls jemand noch nen hinweis für mich hat, immer her damit.

Ich hab die zertifikate übrigens mit openssl erstellt. weiss nicht ob das so optimal hingehauen hat, bin nach der anleitung von lancom vorgegangen...
kann ich irgendwie testen ob die zertifikate ok sind?


gruß
Jan

[backslash]

Hi scatty

e.g. IP network definition

hier stimmen die Netzwerkdefinitionen nicht, d.h. Windows fordert andere Netze, als im LANCOM konfiguriert sind.

gehe doch mal per Telnet auf das LANCOM, starte eine VPN-status Trace (trace # vpn-status) und versuche den Tunnelaufbau erneut,

Gruß
Backslash

[scatty]

Danke erstmal an alle die mir hier weitergeholfen haben!
Sehe nun an meinem LANCOM, dass eine VPN Verbindung aufgebaut ist. Allerdings scheint mein Client das noch nicht zu wissen. Nach zweimaligem IP-Sicherheit wird verhandelt, gibt es nur noch timeouts.

Die Logs auf dem LANCOM sehen wie folgt aus:


trace # vpn-status:

Code: Alles auswählen

[VPN-Status] 2007/02/01 19:25:34,180
IKE log: 192534 Default message_recv: invalid cookie(s) 488913e696c54fb4 3305748
0bc49ba04


[VPN-Status] 2007/02/01 19:25:34,180
IKE log: 192534 Default dropped message from <öfftl. IP des Client> port 500 due to noti
fication type INVALID_COOKIE


[VPN-Status] 2007/02/01 19:25:34,180
IKE info: dropped message from peer unknown <öfftl. IP des Client> port 500 due to notif
ication type INVALID_COOKIE


[VPN-Status] 2007/02/01 19:25:34,180
IKE log: 192534 Default message_recv: invalid cookie(s) 488913e696c54fb4 3305748
0bc49ba04


[VPN-Status] 2007/02/01 19:25:34,180
IKE log: 192534 Default dropped message from <öfftl. IP des Client> port 500 due to noti
fication type INVALID_COOKIE


[VPN-Status] 2007/02/01 19:25:34,180
IKE info: dropped message from peer unknown <öfftl. IP des Client> port 500 due to notif
ication type INVALID_COOKIE


[VPN-Status] 2007/02/01 19:25:46,590
IKE info: The remote server <öfftl. IP des Client>:500 peer def-main-peer id <no_id> sup
ports NAT-T in mode draft
IKE info: The remote server <öfftl. IP des Client>:500 peer def-main-peer id <no_id> sup
ports NAT-T in mode draft


[VPN-Status] 2007/02/01 19:25:46,600
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local pr
oposal 1


[VPN-Status] 2007/02/01 19:25:49,030
IKE info: Phase-1 [responder] for peer NB-JAN between initiator id CN=nb-jan, re
sponder id CN=Device done
IKE info: SA ISAKMP for peer NB-JAN encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2007/02/01 19:25:49,370
IKE info: Phase-2 remote proposal 1 for peer NB-JAN matched with local proposal
1


[VPN-Status] 2007/02/01 19:25:49,660
IKE info: Phase-2 [responder] done with 2 SAS for peer NB-JAN rule ipsec-6-NB-JA
N-pr0-l0-r0
IKE info: rule:' ipsec 10.10.10.0/255.255.255.0 <-> <öfftl. IP des Client>/255.255.255.2
55 '
IKE info: SA ESP [0xf17a000b]  alg 3DES keylength 192 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x5b39e6d1]  alg 3DES keylength 192 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/45000 kb) hard (3600 sec/50000 kb)
IKE info: tunnel between src: <öfftl. IP des LANCOM> dst: <öfftl. IP des Client>


[VPN-Status] 2007/02/01 19:25:49,670
VPN: wait for IKE negotiation from NB-JAN (<öfftl. IP des Client>)

[VPN-Status] 2007/02/01 19:25:50,680
VPN: NB-JAN (<öfftl. IP des Client>) connected

und
trace # vpn-packet

Code: Alles auswählen

[VPN-Packet] 2007/02/01 19:25:49,660
received: <öfftl. IP des Client>-><öfftl. IP des LANCOM>  112  ESP SPI[5b39e6d1]

[VPN-Packet] 2007/02/01 19:25:49,690
received: <öfftl. IP des Client>-><öfftl. IP des LANCOM>  112  ESP SPI[5b39e6d1]

[VPN-Packet] 2007/02/01 19:25:49,690
decrypted: <öfftl. IP des Client>-><öfftl. IP des LANCOM>   96  IP-ENCAP

[VPN-Packet] 2007/02/01 19:25:49,690
decap: <öfftl. IP des Client>->10.10.10.246   60  ICMP ECHOREQUEST

[VPN-Packet] 2007/02/01 19:25:50,690
for send: 10.10.10.246-><öfftl. IP des Client>   60  ICMP ECHOREPLY

[VPN-Packet] 2007/02/01 19:25:50,690
encap: <öfftl. IP des LANCOM>-><öfftl. IP des Client>   80  IP-ENCAP

[VPN-Packet] 2007/02/01 19:25:50,690
encrypted: <öfftl. IP des LANCOM>-><öfftl. IP des Client>  112  ESP SPI[f17a000b]

[VPN-Packet] 2007/02/01 19:25:55,040
received: <öfftl. IP des Client>-><öfftl. IP des LANCOM>  112  ESP SPI[5b39e6d1]

[VPN-Packet] 2007/02/01 19:25:55,040
decrypted: <öfftl. IP des Client>-><öfftl. IP des LANCOM>   96  IP-ENCAP

[VPN-Packet] 2007/02/01 19:25:55,040
decap: <öfftl. IP des Client>->10.10.10.246   60  ICMP ECHOREQUEST

[VPN-Packet] 2007/02/01 19:25:55,040
for send: 10.10.10.246-><öfftl. IP des Client>   60  ICMP ECHOREPLY

[VPN-Packet] 2007/02/01 19:25:55,040
encap: <öfftl. IP des LANCOM>-><öfftl. IP des Client>   80  IP-ENCAP

[VPN-Packet] 2007/02/01 19:25:55,040
encrypted: <öfftl. IP des LANCOM>-><öfftl. IP des Client>  112  ESP SPI[f17a000b]

Vielleicht gibts ja jemanden, der sich für mich mal diese logfiles anschaut.

Des weiteren habe ich noch zwei wichtige Verständnisfrage:
Was für eine IP-Adresse hat der Client nachher im lokalen Netzwerk des LANCOM? und wie wird die bestimmt? muss der Client die vielleicht auch irgendwie wissen?

Und Wie funktioniert eigentlich nachher das richtige routen? woher weiss der client, dass er für eine verbindung mit dem LANCOM Netzwerk (10.10.10.0/24) die VPN Verbindung nehmen soll? habe diesbezüglich bei route print nichts entdecken können.

Danke schonmal für eure mühen!

Gruß
Jan

[eddia]

Hallo Jan,

Sehe nun an meinem LANCOM, dass eine VPN Verbindung aufgebaut ist. Allerdings scheint mein Client das noch nicht zu wissen. Nach zweimaligem IP-Sicherheit wird verhandelt, gibt es nur noch timeouts

das und Dein Log zeigen, dass der Tunnel aufgebaut wurde. Was pingst Du an und wie lautet die VPN-Regel für diese Verbindung?

Was für eine IP-Adresse hat der Client nachher im lokalen Netzwerk des LANCOM? und wie wird die bestimmt?

Keine - hier wird kein Proxy-ARP gemacht sondern einfach nur zwischen dem Lan des Lancoms und der Hostroute des VPN-Clients geroutet.

Und Wie funktioniert eigentlich nachher das richtige routen? woher weiss der client, dass er für eine verbindung mit dem LANCOM Netzwerk (10.10.10.0/24) die VPN Verbindung nehmen soll?

Das wird durch die IPSec-Policies von Windows gesteuert. Ruf mal die ipsec.msc auf und sieh Dir bei den IP-Sicherheitsrichtlinien den Eintrag unter FreeSwan an...

Gruß

Mario

[scatty]

Hi Mario,

danke schonmal für den tip mit der ipsec.msc. da steht ja doch einiges drin
zu den anderen punkten:

Was pingst Du an und wie lautet die VPN-Regel für diese Verbindung?

ich pinge einen win 2003 server im netzwerk des lancoms an.
Wenn du mit VPN-Regel die unter Firewall meinst, dann lautet sie wie folgt:
WIZ_VPN-CLIENT_NB-JAN (wofür auch immer)
und hat auch den Tag auf 1, damit es mit dem routing tag übereinstimmt.

Keine - hier wird kein Proxy-ARP gemacht sondern einfach nur zwischen dem Lan des Lancoms und der Hostroute des VPN-Clients geroutet.

Sorry, aber das hab ich nich verstanden. wenn ich nun einen client im lancom netz habe, unter welcher adresse kann ich meinen remote client erreichen? oder wird einfach die ip die der remote client auf seinem netzwerk device hat verwendet? was wiederum heissen würde, das der lancom einfach alles an diese "komische" ip entsprechend verschlüsseln und über den tunnel schicken müsste. ist das so?

Und dann hab ich noch ne frage. Ich habe in meiner aktuellen konfiguration eine öffentlich IP (nicht statisch). kann das in irgendeiner weise von vorteil sein oder zu problemen führen?


gruß
Jan

[scatty]

anhand des vpn-paket log des lancoms würde ich vermuten, dass der die pakete fleisig weitersendet. da wie ja schon geschrieben ein ping vom remote client zum server im netz des lancom folgendes sagt:



[VPN-Packet] 2007/02/01 19:25:49,690
received: <öfftl. IP des Client>-><öfftl. IP des LANCOM> 112 ESP SPI[5b39e6d1]

[VPN-Packet] 2007/02/01 19:25:49,690
decrypted: <öfftl. IP des Client>-><öfftl. IP des LANCOM> 96 IP-ENCAP

[VPN-Packet] 2007/02/01 19:25:49,690
decap: <öfftl. IP des Client>->10.10.10.246 60 ICMP ECHOREQUEST

[VPN-Packet] 2007/02/01 19:25:50,690
for send: 10.10.10.246-><öfftl. IP des Client> 60 ICMP ECHOREPLY

[VPN-Packet] 2007/02/01 19:25:50,690
encap: <öfftl. IP des LANCOM>-><öfftl. IP des Client> 80 IP-ENCAP

[VPN-Packet] 2007/02/01 19:25:50,690
encrypted: <öfftl. IP des LANCOM>-><öfftl. IP des Client> 112 ESP SPI[f17a000b]



es kommt was rein, wird entpakt, weitergesendet. die antwort kommt wird wieder eingepakt und zurückgesendet. also an sich alles super...

nur kommt hier nichts vernünftiges an:(

irgendwer ne idee warum?

gruß
Jan