default Parameter Frage

hoeschler · Beitrag von **hoeschler** » 04 Sep 2008, 13:04

Hallo,

Ich habe momentan folgendes Problem:

Ich möchte gerne mit der Lancom 7111 verschiedene VPN Zugänge per Zertifikat einrichten. Ich denke mal, die Erstellung dieser mit XCA hat auch gut funktioniert.

Nun stehe ich vor der Eintragung der passenden Parameter in der default-IKE-Proposal Liste. Die Einträge dort sind allerdings mit einer VPN in eine andere Firma belegt und entsprechen nicht den Einstellungen der Einwahl-VPN.

Daher die Frage: Ist es unbedingt nötig, das dort so einzustellen, oder schaffts die Lancom auch, die entsprechenden configs auseinanderzuhalten. Und falls nein: Was gibts für Lösungen dieses Problems?

froeschi62 · Beitrag von **froeschi62** » 04 Sep 2008, 13:49

Hallo,

Du musst die Parameter/Proposals für diese Einwahl VPN Verbindung neu definieren. Das geht aber auch über den Assistenten. Das Feintuning, falls erforderlich, ist dann gegebenenfalls manuell möglich.

Gruß
Dietmar

hoeschler · Beitrag von **hoeschler** » 04 Sep 2008, 14:52

Ja, Problem ist nur, dass die bestehende Verbindung über IPsec im Main Moder arbeitet, was die Zertifikatsverbindungen eben auch tun soll.

Wahrscheinlich müsste ich nur ein bisschen rumprobieren, aber ich hab bisschen Bammel, dass ich die bestehende Verbindung abschieße

froeschi62 · Beitrag von **froeschi62** » 04 Sep 2008, 15:19

Hi,

also ich hatte vor kurzem über eine bestehende VPN Verbindung ein neues VPN angelegt, was dem LC nichts ausgemacht hat. Meine VPN Verbindungen laufen auch im Main Mode/Zertifikate. Allerdings hatte ich dies manuell durchgeführt.
Naja, ein Restrisko bleibt natürlich aber im allgemeinen dürfte es kein Problem darstellen.

Gruß
Dietmar

hoeschler · Beitrag von **hoeschler** » 05 Sep 2008, 10:47

Also ich hab mittlerweile schon eine Menge mehr versucht (manuelle Parameter, mit dem Assistenten) und komme nicht weiter.

Das Problem: Bei der Einwahl und bei Phase 1 schluckt die Firewall sämtliche ankommenden Pakete. Selbst, wenn ich mit dem Assistenten konfiguriere behandelt die FW alles, was ankommt, grundsätzlich mit der DENY_ALL Regel, so dass ich garnicht dazukomm, zu überprüfen, ob sämtliche anderen Einstellungen passen. Das einzige, was ich bei der Einrichtung nicht ändern konnte, waren eben die default_Parameter, da diese auf die bestehende LAN-LAN VPN mit der anderen Firma eingestellt sind.

Langsam weiß ich echt nicht mehr weiter.
Das Handbuch schweigt sich bezgl. dieser Problematik auch aus.

Gibts vielleicht irgendwo eine FAQ, die ich noch nicht gefunden habe? (hier im Forum die helfen nichts, die auf der HP von Lancom auch nicht)

EDIT: Aso, ich hab per 1-klick VPN schonmal Einwahlzugänge gebastelt, deren Firewallregeln genau so aussehen, wie die, die der Assistent für meinen jetzigen Versuch eingerichtet hat. Die VPN Gegenstelle passt auch, nur irgendwie bekomm ichs nicht hin, dass die Lancom die ankommende Verbindung als eben jene VPN-Gegenstelle betrachtet

hoeschler · Beitrag von **hoeschler** » 05 Sep 2008, 12:35

So, jetzt kommt laut fw das paket durch, der shrewsoft tracer macht trotzdem dauernd nen resend

08/09/05 12:33:01 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
08/09/05 12:33:01 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
08/09/05 12:33:01 ii : fragmented packet to 870 bytes ( MTU 1500 bytes )
08/09/05 12:33:01 DB : phase1 resend event scheduled ( ref count = 2 )
08/09/05 12:33:06 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
08/09/05 12:33:06 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
08/09/05 12:33:06 ii : fragmented packet to 870 bytes ( MTU 1500 bytes )
08/09/05 12:33:06 ii : resend 1 packet(s) for phase1 exchange
08/09/05 12:33:11 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
08/09/05 12:33:11 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
08/09/05 12:33:11 ii : fragmented packet to 870 bytes ( MTU 1500 bytes )
08/09/05 12:33:11 ii : resend 1 packet(s) for phase1 exchange
08/09/05 12:33:16 <A : peer tunnel disable message
08/09/05 12:33:16 DB : tunnel stats event canceled ( ref count = 2 )
08/09/05 12:33:16 DB : removing tunnel config references
08/09/05 12:33:16 DB : removing tunnel phase2 references
08/09/05 12:33:16 DB : removing tunnel phase1 references
08/09/05 12:33:16 DB : phase1 resend event canceled ( ref count = 1 )
08/09/05 12:33:16 ii : phase1 removal before expire time
08/09/05 12:33:16 DB : phase1 deleted ( obj count = 0 )
08/09/05 12:33:16 DB : tunnel deleted ( obj count = 0 )
08/09/05 12:33:17 DB : removing all peer tunnel refrences
08/09/05 12:33:17 DB : peer deleted ( obj count = 0 )
08/09/05 12:33:17 ii : ipc client process thread exit ...

froeschi62 · Beitrag von **froeschi62** » 05 Sep 2008, 14:38

Hi,

die Pakete werden fragmentiert. Der MTU Wert ist falsch.
Du solltest die MTU Werte für die VPN Verbindung auf den Wert 1300 ändern.
Das konfigurierst Du im Lancom über Lanconfig im Menü "Kommunikation/Protokolle/MTU-Liste".

Gruß
Dietmar

hoeschler · Beitrag von **hoeschler** » 08 Sep 2008, 16:07

Danke erstmal, ich hab den MTU entsprechend geändert, trotzdem bekomme ich keinen Phase 1 Handshake hin, im log der FW taucht folgendes auf:

IKE log: 160043 Default message_negotiate_sa: no compatible proposal found
IKE log: 160043 Default dropped message from 83.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN
IKE info: dropped message from peer unknown 83.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN

Ich nehme mal stark an, mit dieser Meldung haben sich die Ursachen für die Nicht-Funktionalität radikal verhundertfacht.

Habe auch bisher alle Einstellungen überprüft, mehrere Male die Zertifikate neu erstellt, und auch die config am shrewsoft-client öfters abgeändert, aber so langsam aber sicher bin ich echt ratlos.

froeschi62 · Beitrag von **froeschi62** » 08 Sep 2008, 16:17

Hi,

am Trace erkennt man, dass NAT-T am Router nicht eingeschaltet ist. Schalte es mal ein.

Gruß
Dietmar

hoeschler · Beitrag von **hoeschler** » 08 Sep 2008, 16:23

froeschi62 hat geschrieben:Hi,

am Trace erkennt man, dass NAT-T am Router nicht eingeschaltet ist. Schalte es mal ein.

Gruß
Dietmar

Öhmn meinst du unter VPN -> Allgemein -> NAT-Traversal aktiviert?

Das ist an

froeschi62 · Beitrag von **froeschi62** » 08 Sep 2008, 16:33

Hi,

Ja, das meine ich. Dann ist irgendwo eine Firewall dazwischen, die die UDP Ports 500, 4500 blockt.

Gruß
Dietmar

froeschi62 · Beitrag von **froeschi62** » 09 Sep 2008, 10:51

Hi,

"NO_PROPOSAL_CHOSEN"

überprüfe auch nochmals das IP-Netz, was Du eventuell im VPN Client angegeben hast mit der Netzbeziehung auf der Basis der VPN FW Regel, die der Assistent angelegt hat. Eventuell sind dort Unstimmigkeiten.
Die erzeugten VPN Regeln kannst Du über Telnet mit "show vpn" einsehen.

Gruß
Dietmar

hoeschler · Beitrag von **hoeschler** » 09 Sep 2008, 11:07

Hallo,

Erstmal danke für die bisherige Hilfe. Ich habe es gestern Abend geschafft, dass Client und FW zumindest den ersten IKE Austausch hinbekommen haben. Leider hat mir der Client ein "Phase1 not found" geliefert und abgebrochen. Da ich allerdings keinen Zugang zum FW Log hatte, muss ich nachher erstmal nachsehen, was die dazu sagt. Weiteres poste ich, sobald ich Ergebnisse hab und nicht weiterkomme

froeschi62 · Beitrag von **froeschi62** » 09 Sep 2008, 11:12

Hi,

ok, prima! Ich drücke Dir die Daumen.

Viele Grüße
Dietmar

hoeschler · Beitrag von **hoeschler** » 10 Sep 2008, 09:17

Jetzt mal ne doofe Frage zu Beginn: Im XCA Tutorial

http://www.vpnforum.de/wiki/index.php/S ... ng_mit_XCA

steht unten irgendwas vom Diffie-Hellmann Parameter. Ich hat da einen 1024er mit openssl zusätzlich erstellt, wüsste aber nicht, wozu ich den brauchen soll, bzw. wo der hinmuss.

Weiterhin hab ich immernoch das gleiche Problem:

Der Client sendet ein IKE Paket. Auf der Firewall im VPN Log taucht dann die Message "no_compatible_proposal_chosen" auf, sendet die Info wahrscheinlich dann zurück an den Client, der mir daraufhin erklärt, dass der Aufbau in Phase 1 fehlgeschlagen ist. Nat:t ist an, ich hab auch erst gedacht, dass mein Router zuhause evtl. blockt, hab dort den 4500er UDP Port freigeschaltet und erst danach festgestellt, dass der Tunnelaufbau bis dahin garnicht kommt.

Daher auch gleich die nächste Frage: Wie genau kommt der Handshake zustande? Was für Informationen werden da genau ausgetauscht? Steht in den ersten IKE Paketen nur grundsätzlich was über die zu verwendenden Proposals, oder versucht der Client sofort, den ASN1.Distinguished Name zu übermitteln?

Weil wenn das so ist, kann ja im Endeffekt der Fehler nur entweder bei der Einstellung der Identitäten in der Lancom liegen, oder es ist an der Zertifikatsstruktur grundsätzlich was falsch.

Daher gleich paar mehr Fragen: Ich hab Server und Client Zertifikat als PKCS#12 Container mit Certificate Chain exportiert. Das Server Zertifikat hab ich beim Export nicht mit einem Passwort abgesichert und das p12 File per WebConfig in die Lancom geladen.

Das Clientzertifikat liegt ebenfalls im p12 Format vor. Im ShrewSoft Client habe ich die Authentication Method auf Mutual RSA+XAuth gestellt, die entsprechenden Zeilen in den credentials alle auf den PKCS Container mit dem Clientzertifikat gesetzt (also Server Certificate Authority File, Client certificate File, Client private Key file).

War das soweit schonmal richtig, oder habe ich da nochwas vergessen?

Ach so, die Pahse 1 config:

Exchange Type : main
DH - Exchange: group 2
Cipher: AES 128
Hash: sha1

Die Proposals in der Lancom für die VPN Gegenstelle sind auf RSA-AES-SHA und RSA-AES-MD5 gestellt. Daher verstehe ich nicht ganz, was es da nicht zu finden gibt