[Openswan Users] incomplete ISAKMP SA ...

[Lorens Kockum]

On Wed Mar 31 22:48:02 2004, paul wrote:
> On Wed, 31 Mar 2004, andrei wrote:
> > "remote" #6: protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 
> > but are 17/0 
> 
> That is a bug in the Cisco pix. A workaround for this was added
> recently.
> 
> Use: rightprotoport=17/%any

I found this by Googling. This is the only message I've found
that says there is a solution to this problem except editing the
source of openswan or of the PIX . . . but it doesn't work for
me.

I have a simple configuration, I want a tunnel between my Debian
Linux and a PIX, using a pre-shared key, all public IPs and
static routes without any NAT.

conn cx
    type=tunnel
    authby=secret
    left=${LINUX_IPSEC}
    leftsubnet=${SERVER_BEHIND_LINUX}/32
    leftnexthop=%defaultroute
    rightnexthop=%defaultroute
    right=${PIX_IPSEC}
    rightsubnet=${SERVER_BEHIND_PIX}
    auto=add

002 "cx" #1: initiating Main Mode
104 "cx" #1: STATE_MAIN_I1: initiate
002 "cx" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "cx" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "cx" #1: received Vendor ID payload [XAUTH]
003 "cx" #1: received Vendor ID payload [Dead Peer Detection]
003 "cx" #1: received Vendor ID payload [Cisco-Unity]
003 "cx" #1: ignoring unknown Vendor ID payload [ea8d2ff1f939222668d5c0b4e3b7165b]
002 "cx" #1: I did not send a certificate because I do not have one.
002 "cx" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "cx" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "cx" #1: protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0
218 "cx" #1: STATE_MAIN_I3: INVALID_ID_INFORMATION

The pluto debug logs only add 

	complete state transition with (null)

however the connection attempts seem to continue with:

Jan 25 14:19:14 io-c pluto[20366]: | *received 84 bytes from 62.159.228.100:500 on lo:6
...
Jan 25 14:19:14 io-c pluto[20366]: | peer and cookies match on #1, provided msgid 00000000 vs 00000000
Jan 25 14:19:14 io-c pluto[20366]: | state object #1 found, in STATE_MAIN_I3
...
Jan 25 14:19:14 io-c pluto[20366]: | received encrypted packet from ${PIX_IPSEC}:500
Jan 25 14:19:14 io-c pluto[20366]: | decrypting 56 bytes using algorithm OAKLEY_3DES_CBC
Jan 25 14:19:14 io-c pluto[20366]: | decrypted:
Jan 25 14:19:14 io-c pluto[20366]: |   7b e1 b4 bf  2c 9a 23 c8  f8 66 28 91  a5 03 aa 41
Jan 25 14:19:14 io-c pluto[20366]: |   c0 28 24 1a  33 4b 21 8e  00 00 00 1c  00 00 00 01
Jan 25 14:19:14 io-c pluto[20366]: |   01 10 60 02  a2 ea 63 d8  b8 5a 91 fc  1f 4a 88 ec
Jan 25 14:19:14 io-c pluto[20366]: |   fa c3 30 e1  00 00 00 00
Jan 25 14:19:14 io-c pluto[20366]: | next IV:  f3 81 f6 ab  79 0c 1a 99
Jan 25 14:19:14 io-c pluto[20366]: "cx" #1: next payload type of ISAKMP Hash Payload has an unknown value: 123
Jan 25 14:19:14 io-c pluto[20366]: "cx" #1: malformed payload in packet
Jan 25 14:19:14 io-c pluto[20366]: "cx" #1: sending notification PAYLOAD_MALFORMED to ${PIX_IPSEC}:500

Does that mean that the INVALID_ID_INFORMATION doesn't matter?

Assuming the problem is the Phase 1 ID Payload, I've fumbled
around with various combinations of

    rightprotoport=17/%any
    leftprotoport=17/%any
    rightprotoport=17/0
    leftprotoport=17/0
    leftprotoport=17/500
    esp=3des-md5-96
    keyexchange=ike
    pfs=no

I thought that maybe "A workaround for this was added recently."
said in March 2004 might not have made it into 2.2.0, so I've
upgraded to 2.3.0.

No significant change (the quoted lines are from 2.3.0). When I
get different messages, it's either

	the protocol for leftprotoport and rightprotoport must be the same

        cannot initiate connection with ID wildcards (kind=CK_TEMPLATE)

or even

	021 no connection named "cx"

which would be when I enter something invalid, I suppose.  I do
an /etc/init.d/ipsec stop and start between each change.

What do I do?  I don't especially want to want to edit the
source (I like debian packages), but if that's all that is
needed, I'll be happy to.

Unfortunately I don't think I could get the PIX to upgrade, but
just in case does anyone have the CSCbugid and/or a PIX version
number that would work?

Thanks for any help. HAND