Neuerdings Probleme mit Phase 2

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
tbc233
Beiträge: 350
Registriert: 01 Feb 2005, 21:56

Neuerdings Probleme mit Phase 2

Beitrag von tbc233 »

Ich habe mir mittlerweile seit einiger Zeit in etwa folgendes Setup eines VPN-Clients angewöhnt (ohne bisher darüber nachgedacht zu haben wie elegant das ist):

1) Erstellen der Grundeinträge mit dem Wizard, VPN-Client mit PSK

2) Um zu erreichen das dauerhaft LZS Komprimierung verwendet wird (der WIZ-TN-AES-MD5-96 wird ja immer wieder überschrieben), erstelle ich in ipsec-proposals eine Kopie vom WIZ-TN-AES-MD5-96, in der ich LZS aktiviere. Diese nenne ich STANDARD-LZS

3) Ich erstelle in den ipsec-proposals einen Eintrag STANDARD-CLIENT, der nur ein einziges Proposal enthält, nämlich STANDARD-LZS.

4) Ich weise unter Verbindungs-Parameter dem Eintrag das STANDARD-CLIENT als ipsec-proposal zu

-> bei künftigen VPN Profilen erspare ich mir all diese Schritte und brauche nur mehr das STANDARD-CLIENT als proposal zuweisen - fertig.

Damit bin ich eigentlich immer gut gefahren. Neuerdings (ich denke seit 8.0 ODER seit der neuesten VErsion des Clients, bin mir aber nicht sicher) häufen sich aber die Probleme. Der Verbindungsaufbau bricht bei Phase2 ab. Das schaut dann zb. so aus:

Code: Alles auswählen

[VPN-Status] 2010/08/05 15:44:17,460
IKE info: Phase-2 failed for peer PROFILNAME: no rule matches the phase-2 ids  192.168.190.218 <->  192.168.190.0/255.255.255.0
IKE log: 154417.000000 Default message_negotiate_sa: no compatible proposal found
IKE log: 154417.000000 Default dropped message from 81.10.151.90 port 4294958934 due to notification type NO_PROPOSAL_CHOSEN
IKE info: dropped message from peer PROFILNAME 81.10.151.90 port 4294958934 due to notification type NO_PROPOSAL_CHOSEN
(die 192.168.190.218 stammt aus dem Pool für Einwahladressen, es wird IKE config mode verwendet)

Oft ging es nach einer neuerlichen Einrichtung des Profils wieder eine zeitlang. Heute konnte ich aber mal einen Fall per Fernwartung dingfest machen. Ich habe nachvollziehbar festgestellt, dass die Verbindung klappt, sobald ich meiner ipsec-proposal-liste einen weiteren Eintrag (zb. WIZ-TN-AES-MD5-96) hinzufüge. Dann klappt der Verbindungsaufbau - mit Komprimierung (was für mich heisst das trotzdem eine Einigung auf das erste Proposal STANDARD-LZS erfolgt). sobald ich dieses zweite proposal wieder aus der Liste nehme, klappts wieder nicht.

Hat jemand eine Idee was hier schief läuft? Braucht der Client neuerdings zwingend zumindest zwei Proposals?
Liebe Grüße,
michael
Antworten