1611+ vs. Linux: Keine Verbindung: invalid next payload type

[marsupilami]

Hallo,

kurz vornweg, meine Kenntnisse betreffs IPsec sind nahe null. Ich versuche, von einem Linuxrechner mit OpenSwan zu einen Lancom 1611+ eine Verbindung aufzubauen. Das scheint auch fast zu klappen, aber dannn hat der Lancom doch was zu meckern: invalid next payload type <Unknown 55> in payload of type 8
Leider weiß ich nicht, wie ich rausfinde, was ihn stört. Habt ihr ev. eine Idee?

Hier ein Trace des Verbindungsaufbaus:

Code: Alles auswählen

| LANCOM 1611+
| Ver. 6.06.0012 / 27.03.2006
| SN.  XXXXXXXXXXXX
| Copyright (c) LANCOM Systems

root@router:/
> trace # vpn-status
VPN-Status      ON

root@router:/
> trace # vpn-packet
VPN-Packet      ON

root@router:/
>
[VPN-Status] 2009/08/27 13:36:13,380
IKE info: The remote server xxx.xx.xxx.xxx:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server xxx.xx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server xxx.xx.xxx.xxx:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
[VPN-Status] 2009/08/27 13:36:13,380
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 1
[VPN-Status] 2009/08/27 13:36:13,900
IKE log: 133613 Default message_parse_payloads: invalid next payload type <Unknown 55> in payload of type 8
[VPN-Status] 2009/08/27 13:36:13,910
IKE log: 133613 Default dropped message from xxx.xx.xxx.xxx port 500 due to notification type INVALID_PAYLOAD_TYPE
[VPN-Status] 2009/08/27 13:36:13,910
IKE info: dropped message from peer unknown xxx.xx.xxx.xxx port 500 due to notification type INVALID_PAYLOAD_TYPE
[VPN-Status] 2009/08/27 13:36:14,200
IKE log: 133614 Default ipsec_get_keystate: no keystate in ISAKMP SA 009d8e40
[VPN-Status] 2009/08/27 13:36:24,300
IKE log: 133624 Default ipsec_get_keystate: no keystate in ISAKMP SA 009d8e40
[VPN-Status] 2009/08/27 13:36:45,080
IKE log: 133645 Default message_recv: invalid cookie(s) 3ff4a03987818a1d 74beebe88bd8ff17
[VPN-Status] 2009/08/27 13:36:45,080
IKE log: 133645 Default dropped message from xxx.xx.xxx.xxx port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/08/27 13:36:45,080
IKE info: dropped message from peer unknown xxx.xx.xxx.xxx port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/08/27 13:37:01,280
IKE log: 133701 Default message_recv: invalid cookie(s) 3ff4a03987818a1d 74beebe88bd8ff17
[VPN-Status] 2009/08/27 13:37:01,280
IKE log: 133701 Default dropped message from xxx.xx.xxx.xxx port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/08/27 13:37:01,280
IKE info: dropped message from peer unknown xxx.xx.xxx.xxx port 500 due to notification type INVALID_COOKIE

Die Konfiguration auf der Linuxkiste sieht so aus:

Code: Alles auswählen

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        nat_traversal=yes
        nhelpers=0
        plutodebug="all"
        klipsdebug="all"

# Add connections here

conn server
        authby=secret
        pfs=yes
        rekey=yes
        keyingtries=3
        type=transport
        left=%defaultroute
        leftprotoport=17/1701
        right=yyy.yy.yyy.yyy
        rightprotoport=17/1701
        leftid=abcd@xyz.ag
        rightid=abcd@xyz.ag
        auto=ignore
        aggrmode=yes
        ike=aes-md5-modp1024
        forceencaps=yes
        #leftmodecfgclient=yes
        compress=yes

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

liebe Grüße,

Jan

[backslash]

Hi marsupilami

das Problem dürfte hier liegen:

Code: Alles auswählen

        type=transport 
        (...) 
        leftprotoport=17/1701 
        (...) 
        rightprotoport=17/1701 

damit schaltest du das VPN auf L2TP über IPSec... Das wird vom LANCOM nicht unterstützt.

Konfiguriere es für normales IPSec, also Tunnel-Mode, und kein left/rightprotoport.

Desweiteren solltest du die Komression deaktivieren, da Deflate nicht besonders effizient ist

Gruß
Backslash

[marsupilami]

Hallo backslash, danke für deine Ideen. Ich habe jetzt left- und rightprotoport auskommentiert, sowie in den Tunnelmodus geschalten. Die Fehlermeldung bleibt gleich:
IKE log: 133613 Default message_parse_payloads: invalid next payload type <Unknown 55> in payload of type 8
wobei sich die Zahl hinter IKE log und hinter Unknown bei jedem versuch ändern.

hier mal noch eine Ausgabe von Openswan:

Code: Alles auswählen

root@desktop:~# /etc/init.d/ipsec start
ipsec_setup: Starting Openswan IPsec U2.4.12/K2.6.28-15-generic...
root@desktop:~# ipsec auto --add server
root@desktop:~# ipsec auto --verbose --up server
002 "server" #1: initiating Aggressive Mode #1, connection "server"
112 "server" #1: STATE_AGGR_I1: initiate
003 "server" #1: ignoring unknown Vendor ID payload [eeefa37809e32ad4de4f6b010c26a640]
003 "server" #1: received Vendor ID payload [Dead Peer Detection]
002 "server" #1: Aggressive mode peer ID is ID_USER_FQDN: 'abcd@yxz.ag'
002 "server" #1: Aggressive mode peer ID is ID_USER_FQDN: 'abcd@yxz.ag'
002 "server" #1: transition from state STATE_AGGR_I1 to state STATE_AGGR_I2
004 "server" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5 group=modp1024}
002 "server" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}
117 "server" #2: STATE_QUICK_I1: initiate
010 "server" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "server" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "server" #2: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "server" #2: starting keying attempt 2 of at most 3, but releasing whack
root@desktop:~#

Zugegebenermaßen erscheint mir das mit dem L2TP auch nicht ganz schlüssig, da der Windows-Lancomclient mir ja eine IP-Adresse aus dem Zielnetzwerk auf meiner Maschine gibt, was IPsec selbst ja nicht leisten kann?
Irgendwie hab ich das Shared Secret im Verdacht, da der Fehler erst bei der Übermittlung der ersten verschlüsselten Daten (laut Wireshark) auftritt. Alerdings hab ich das auch schon dreimal überprüft, da steht in der INI bei Secret das gleiche wie unter Linux in der ipsec.conf...

[backslash]

Hi marsupilami

also hier ist doch die Phase 1 hochgekommen:

004 "server" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5 group=modp1024}

und nur es scheitert an der Phase 2, also an den Netzbeziehungen und oder Verschlüsselungs-Protokollen...

031 "server" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

d.h. du kannst auf dem LANCOM nicht mehr die gleiche Meldung bekommen haben... Mach doch nochmal einen VPN-Status-Trace auf dem LANCOM

Gruß
Backslash

[marsupilami]

Hallo Backslash, tut mir leid, daß das so lange gedauert hat, hier sind die Meldungen, die ich eben erhalten habe:

Lancom:

Code: Alles auswählen

#
| LANCOM 1611+
| Ver. 6.06.0012 / 27.03.2006
| SN.  xxxxxxxxxxxx
| Copyright (c) LANCOM Systems
server, Connection No.: 002 (WAN)
root@server:/
> trace # vpn-status
VPN-Status      ON
root@server:/
> trace # vpn-packet
VPN-Packet      ON
root@server:/
>
[VPN-Status] 2009/09/04 09:35:40,620
IKE info: The remote server aaa.aa.aaa.aaa:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server aaa.aa.aaa.aaa:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server aaa.aa.aaa.aaa:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server aaa.aa.aaa.aaa:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server aaa.aa.aaa.aaa:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server aaa.aa.aaa.aaa:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
[VPN-Status] 2009/09/04 09:35:40,630
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 1
[VPN-Status] 2009/09/04 09:35:41,060
IKE log: 093541 Default message_parse_payloads: reserved field non-zero: 58
[VPN-Status] 2009/09/04 09:35:41,060
IKE log: 093541 Default dropped message from aaa.aa.aaa.aaa port 500 due to notification type PAYLOAD_MALFORMED
[VPN-Status] 2009/09/04 09:35:41,060
IKE info: dropped message from peer unknown aaa.aa.aaa.aaa port 500 due to notification type PAYLOAD_MALFORMED
[VPN-Status] 2009/09/04 09:35:41,310
IKE log: 093541 Default ipsec_get_keystate: no keystate in ISAKMP SA 00a56360
[VPN-Status] 2009/09/04 09:35:51,380
IKE log: 093551 Default ipsec_get_keystate: no keystate in ISAKMP SA 00a56360
[VPN-Status] 2009/09/04 09:36:11,150
IKE log: 093611 Default message_recv: invalid cookie(s) 141d4af60c2bd7e3 6061ed5140d628b3
[VPN-Status] 2009/09/04 09:36:11,150
IKE log: 093611 Default dropped message from aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:36:11,150
IKE info: dropped message from peer unknown aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:36:51,480
IKE log: 093651 Default message_recv: invalid cookie(s) 141d4af60c2bd7e3 6061ed5140d628b3
[VPN-Status] 2009/09/04 09:36:51,480
IKE log: 093651 Default dropped message from aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:36:51,480
IKE info: dropped message from peer unknown aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:37:01,580
IKE log: 093701 Default message_recv: invalid cookie(s) 141d4af60c2bd7e3 6061ed5140d628b3
[VPN-Status] 2009/09/04 09:37:01,580
IKE log: 093701 Default dropped message from aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:37:01,580
IKE info: dropped message from peer unknown aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:37:20,740
IKE log: 093720 Default message_recv: invalid cookie(s) 141d4af60c2bd7e3 6061ed5140d628b3
[VPN-Status] 2009/09/04 09:37:20,740
IKE log: 093720 Default dropped message from aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE
[VPN-Status] 2009/09/04 09:37:20,740
IKE info: dropped message from peer unknown aaa.aa.aaa.aaa port 500 due to notification type INVALID_COOKIE

und hier der vom OpenSwan:

Code: Alles auswählen

root@desktop:~# /etc/init.d/ipsec start
ipsec_setup: Starting Openswan IPsec U2.4.12/K2.6.28-15-generic...
root@desktop:~# ipsec auto --add server
root@desktop:~# ipsec auto --verbose --up server
002 "server" #1: initiating Aggressive Mode #1, connection "server"
112 "server" #1: STATE_AGGR_I1: initiate
003 "server" #1: ignoring unknown Vendor ID payload [eeefa37809e32ad4de4f6b010c26a640]
003 "server" #1: received Vendor ID payload [Dead Peer Detection]
002 "server" #1: Aggressive mode peer ID is ID_USER_FQDN: 'xxx@yyy.ag'
002 "server" #1: Aggressive mode peer ID is ID_USER_FQDN: 'xxx@yyy.ag'
002 "server" #1: transition from state STATE_AGGR_I1 to state STATE_AGGR_I2
004 "server" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5 group=modp1024}
002 "server" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}
117 "server" #2: STATE_QUICK_I1: initiate
010 "server" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "server" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "server" #2: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "server" #2: starting keying attempt 2 of at most 3, but releasing whack
root@desktop:~#

Grüße,

Jan

[backslash]

Hi marsupilami

zumindest sagt das LANCOM jetzt nicht "invalid payload type" an sondern "payload malformed", was i.A. auf einen falschen preshared key schließen läßt. Prüfe mal den Key...

Beachte dabei, daß das LANCOM nicht alle Sonderzeichen im Key zuläßt, weil sie sich abhängig vom verwendeten Betriebssystem in ihrer Codierung unterscheiden. Im Key läßt das LANCOM nur folgende Zeichen zu:

#ABCDEFGHIJKLMNOPQRSTUVWXYZ@{|}~!$%&'()*+-,/:;<=>?[\]^_.0123456789abcdefghijklmnopqrstuvwxyz `

Gruß
Backslash