VPN Client 2.10 <> FW 7.70 Prosposal Problem

COMCARGRU · Beitrag von **COMCARGRU** » 29 Sep 2009, 10:04

Moin zusammen,

jeweils mit dem Assistenten auf dem Client wie auf dem Router die VPN Verbindung mit folgendem Ergebnis eingerichtet:

IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2

IKE log: 093215.000000 Default ipsec_get_keystate: no keystate in ISAKMP SA 0167d020

IKE log: 093219.000000 Default ipsec_get_keystate: no keystate in ISAKMP SA 0167d020

Also die Fehlermeldung, daß die Proposals nicht stimmen irrtiert mich dann doch! Entsprechend schlägt die Verbindung fehl. Da sowohl ein Kollege die Verbindung konfiguiert hatte, als auch ich nochmals komplett neu, schließe ich eine Fehler bei PSK, etc. aus...

Was ist da los? Mit den bishgerigen Clients (< 2.10) gab es sowas nicht.

Danke
COMCARGRU

backslash · Beitrag von **backslash** » 29 Sep 2009, 17:13

Hi COMCARGRU,

es ist keine "Fehlermeldung" in dem Sinne... Die Default-Proposal-Liate enthält mehrere Proposals, die der Reihe nach abgearbeitet werden:

PSK-AES-MD5, PSK-AES-SHA, PSK-BLOW-MD5, PSK-BLOW-SHA, etc...

Der Client fordern nun offenbar AES+SHA, was aber erst an zweiter Stelle in der Proposal-Liste steht, daher steht im Trace, daß beim ersten Proposal SHA und MD5 nicht zusammenpassen und erst das zweite Proposal matcht.

Das ist alles...

Du kannst den Client so konfigurieren, daß er (nur) MD5 als Sicherung fordert, dann bist du die Meldung im Trace los. Ebenso könntest du die Proposals in der Proposal-Liste umstellen, das unterdrückt für den Client die Meldung, dafür kommt sie dann bei Gegenstellen, die MD5 fordern...

Am einfachsten ist es, das zu ignorieren...

Gruß
Backslash

COMCARGRU · Beitrag von **COMCARGRU** » 29 Sep 2009, 18:54

Hi,

häm das Gerät mit dieser Meldung ist jetzt wieder im Land unterwegs. Vor nächster Woche hab ich das nicht. Im Trace des Routers war das aber die einzige auffälige Fehlermeldung... - Ein anderer Grund für den Verbindungsfehlschlag war nicht zu sehen.

Alle anderen Clients laufen problemlos!

Gruß
COMCARGRU

COMCARGRU · Beitrag von **COMCARGRU** » 11 Nov 2009, 15:30

Hi,

hier jetzt endlich mal ein Trace vom Router und vom Client:

Trace des Clients:

11.11.2009 15:17:02IPSec: Start building connection
11.11.2009 15:17:02Ike: phase1:name(xxx) - outgoing connect request - aggressive mode.
11.11.2009 15:17:02Ike: XMIT_MSG1_AGGRESSIVE - xxx
11.11.2009 15:17:08Ike: RECV_MSG2_AGGRESSIVE - xxx
11.11.2009 15:17:08Ike: IKE phase I: Setting LifeTime to 28800 seconds
11.11.2009 15:17:08Ike: IkeSa negotiated with the following properties -
11.11.2009 15:17:08 Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=128
11.11.2009 15:17:08IPSec: Final Tunnel EndPoint is:xxx.xxx.xxx.xxx
11.11.2009 15:17:08Ike: xxx ->Support for NAT-T version - 9
11.11.2009 15:17:08Ike: XMIT_MSG3_AGGRESSIVE - xxx
11.11.2009 15:17:08Ike: IkeSa negotiated with the following properties -
11.11.2009 15:17:08 Authentication=PRE_SHARED_KEY,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=128
11.11.2009 15:17:08Ike: Turning on DPD mode - xxx
11.11.2009 15:17:08Ike: phase1:name(xxx) - connected
11.11.2009 15:17:08SUCCESS: IKE phase 1 ready
11.11.2009 15:17:08IPSec: Phase1 is Ready - IkeIndex=13
11.11.2009 15:17:08IPSec: Quick Mode is Ready: IkeIndex = 0000000d , VpnSrcPort = 500
11.11.2009 15:17:08IPSec: Assigned IP Address: xxx.xxx.xxx.xxx
11.11.2009 15:17:09IkeQuick: XMIT_MSG1_QUICK - xxx
11.11.2009 15:17:22IkeQuick: phase2:name(xxx) - error - retry timeout - max retries
11.11.2009 15:17:22ERROR - 4037: IKE(phase2):Waiting for message2, retry timeout - max retries - xxx.
11.11.2009 15:17:22IPSec: Disconnected from xxx on channel 1.

Trace des Routers:

[TraceStarted] 2009/11/11 15:15:21,435
Used config:
# Trace config
trace + VPN-Status

[VPN-Status] 2009/11/11 15:16:35,714 Devicetime: 2009/11/11 15:16:35,680
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote client xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> is NCP LANCOM Serial Number Protocol 1.0 with serial number xxx
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xxx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
[VPN-Status] 2009/11/11 15:16:36,105 Devicetime: 2009/11/11 15:16:35,680
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2
[VPN-Status] 2009/11/11 15:16:36,792 Devicetime: 2009/11/11 15:16:36,760
IKE log: 151636.000000 Default ipsec_get_keystate: no keystate in ISAKMP SA 01289920
[VPN-Status] 2009/11/11 15:16:40,714 Devicetime: 2009/11/11 15:16:40,680
IKE log: 151640.000000 Default ipsec_get_keystate: no keystate in ISAKMP SA 01289920
[VPN-Status] 2009/11/11 15:16:43,714 Devicetime: 2009/11/11 15:16:43,680
IKE log: 151643.000000 Default ipsec_get_keystate: no keystate in ISAKMP SA 01289920
[VPN-Status] 2009/11/11 15:16:46,714 Devicetime: 2009/11/11 15:16:46,680
IKE log: 151646.000000 Default ipsec_get_keystate: no keystate in ISAKMP SA 01289920

Das einzige was grundsätzlich aufällt ist das die Zeit etwas differiert, aber mehr will mir das im Moment nicht sagen. Die Verbindung im Router ist mit dem Assi erstellt und identisch zu den anderen und für den Client trifft das gleiche zu bis auf die Benutzer spezifischen Unterschiede (FQUN, PSK, etc.)

Wo hängt's?

Edit: IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5

Das will mir eigentlich nicht recht einleuchten, da im Client bei IKE-Richtlinie und IPSec-Richtlinie als einziges jeweils AES und MD5 angelegt ist. SHA taucht dort nicht auf! Er dürfte also gar kein SHA verwenden? Hat hier die Installation des Clients einen Knall? Wurde aber auch schonmal neu installiert!

Danke
COMCARGRU