[Openswan Users] not enough room in input packet for ISAKMP

[Pompon]

Hi all,

I am trying to resolv a problem with phase2 establishment with a
cicso-Pix515 peer. My server is a debian stable with kernel 2.6.8 and the
lastest stable version of klips (2.4.6) ans openswan.

I already have VPNs working with some linux box running racoon or openswan
but it doesn't work with cisco.

Let's first look at the log :

Oct 19 16:23:36 localhost ipsec__plutorun: Starting Pluto subsystem...
Oct 19 16:23:36 localhost pluto[8227]: Starting Pluto (Openswan Version
2.2.0 X.509-1.5.4 PLUTO_USES_KEYRR)
Oct 19 16:23:36 localhost pluto[8227]:   including NAT-Traversal patch
(Version 0.6c) [disabled]
Oct 19 16:23:36 localhost pluto[8227]: ike_alg_register_enc(): Activating
OAKLEY_AES_CBC: Ok (ret=0)
Oct 19 16:23:36 localhost pluto[8227]: Using KLIPS IPsec interface code
Oct 19 16:23:36 localhost pluto[8227]: Changing to directory
'/etc/ipsec.d/cacerts'
Oct 19 16:23:36 localhost pluto[8227]: Changing to directory
'/etc/ipsec.d/aacerts'
Oct 19 16:23:36 localhost pluto[8227]: Changing to directory
'/etc/ipsec.d/ocspcerts'
Oct 19 16:23:36 localhost pluto[8227]: Changing to directory
'/etc/ipsec.d/crls'
Oct 19 16:23:36 localhost pluto[8227]:   Warning: empty directory
Oct 19 16:23:36 localhost pluto[8227]: added connection description "BT"
Oct 19 16:23:36 localhost pluto[8227]: listening for IKE messages
Oct 19 16:23:36 localhost pluto[8227]: adding interface ipsec0/eth0
213.30.xxx.xxx
Oct 19 16:23:36 localhost pluto[8227]: loading secrets from
"/etc/ipsec.secrets"
Oct 19 16:23:36 localhost pluto[8227]:   loaded private key file
'/etc/ipsec.d/private/karlmarxKey.pem' (1679 bytes)
Oct 19 16:23:36 localhost pluto[8227]: "BT" #1: initiating Main Mode
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: transition from state
STATE_MAIN_I1 to state STATE_MAIN_I2
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring Vendor ID payload
[XAUTH]
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: received Vendor ID payload
[Dead Peer Detection]
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring Vendor ID payload
[Cisco-Unity]
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring Vendor ID payload
[03d6443be45f8cd79702d5e5a384f2c9]
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: I did not send a certificate
because I do not have one.
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: transition from state
STATE_MAIN_I2 to state STATE_MAIN_I3
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: Peer ID is ID_IPV4_ADDR: '
217.34.yyy.yyy'
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: transition from state
STATE_MAIN_I3 to state STATE_MAIN_I4
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ISAKMP SA established
Oct 19 16:23:37 localhost pluto[8227]: "BT" #2: initiating Quick Mode
PSK+ENCRYPT+COMPRESS+TUNNEL+UP {using isakmp#1}
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring informational
payload, type IPSEC_INITIAL_CONTACT
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: received and ignored
informational message
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring informational
payload, type NO_PROPOSAL_CHOSEN
Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: received and ignored
informational message
Oct 19 16:23:47 localhost pluto[8227]: packet from 217.34.yyy.yyy:500: not
enough room in input packet for ISAKMP Message
Oct 19 16:23:47 localhost pluto[8227]: packet from 217.34.yyy.yyy:500:
sending notification PAYLOAD_MALFORMED to 217.34.yyy.yyy:500
Oct 19 16:23:52 localhost pluto[8227]: packet from 217.34.yyy.yyy:500: not
enough room in input packet for ISAKMP Message
Oct 19 16:23:52 localhost pluto[8227]: packet from 217.34.yyy.yyy:500:
sending notification PAYLOAD_MALFORMED to 217.34.yyy.yyy:500
Oct 19 16:23:57 localhost pluto[8227]: packet from 217.34.yyy.yyy:500: not
enough room in input packet for ISAKMP Message
Oct 19 16:23:57 localhost pluto[8227]: packet from 217.34.yyy.yyy:500:
sending notification PAYLOAD_MALFORMED to 217.34.yyy.yyy:500


Now my history : I was running racoon on the 26sec native stack before and
had the same type of problem : the racoon error message was "Package shorter
than ISAKMP header". I reach to pass through this error by configuring
strict security policies matching exactly the cisco implemented policies,
but it was not so easy especially because the remote subnet is a two
consecutive ip range defined by a /31 mask. Then we constat a very strange
problem ater 3 or 4 days of use, all packest to a raduis server (on our
subnet behind the VPN) was still seen and decrypted by 26sec but never
forwarded to radius just as if they were simply dropped by an invisible
kernel part.
So we decided to test openswan and KLIPS stack over kernel 2.6(.8 : debian
stable) as it seems to be a more stable and proved way of doing ipsec.

But it seems that I found sort of a problem already seen, related either to
the distant subnet, or the cisco policies.

So here are my questions :

Did you heard about such a problem?
Did you know how to implement specific security policy with openswan related
to a tunnel?
Did you know how/if a security policies declared on cisco could influence
the phase2 negociation?

My configuration :

conn BT
        authby=secret
        type=tunnel
        auto=start
        compress=yes
        pfs=no
        keyexchange=ike
        esp="3des-sha1-96"
        ikelifetime=28800
        #ike="3des-sha1"
        # Left security gateway, subnet behind it, next hop toward right.
        left=213.30.xxx.xxx
        leftsubnet=213.30.xxx.aaa/32
        leftnexthop=213.30.xxx.bbb
        # Right security gateway, subnet behind it, next hop toward left.
        right=217.34.yyy.yyy
        rightsubnet=217.41.zzz.zzz/31

Notice that I have tried lot's of configs and especially with our without
compress, pfs, keyexchange, esp, ikelifetime, etc. I also have debug
versions of the log that could perhaps help someone

Many thanks,
Jean-Michel
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20061019/a29d1ce7/attachment-0001.html