<span class="nw" id="_user_users@openswan.org"><br>Hi all,<br><br>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.<br><br>I already have VPNs working with some linux box running racoon or openswan but it doesn't work with cisco.<br><br>Let's first look at the log :<br><br>Oct 19 16:23:36 localhost ipsec__plutorun: Starting Pluto subsystem...
<br>Oct 19 16:23:36 localhost pluto[8227]: Starting Pluto (Openswan Version 2.2.0 X.509-1.5.4 PLUTO_USES_KEYRR)<br>Oct 19 16:23:36 localhost pluto[8227]: including NAT-Traversal patch (Version 0.6c) [disabled]<br>Oct 19 16:23:36 localhost pluto[8227]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
<br>Oct 19 16:23:36 localhost pluto[8227]: Using KLIPS IPsec interface code<br>Oct 19 16:23:36 localhost pluto[8227]: Changing to directory '/etc/ipsec.d/cacerts'<br>Oct 19 16:23:36 localhost pluto[8227]: Changing to directory '/etc/ipsec.d/aacerts'
<br>Oct 19 16:23:36 localhost pluto[8227]: Changing to directory '/etc/ipsec.d/ocspcerts'<br>Oct 19 16:23:36 localhost pluto[8227]: Changing to directory '/etc/ipsec.d/crls'<br>Oct 19 16:23:36 localhost pluto[8227]: Warning: empty directory
<br>Oct 19 16:23:36 localhost pluto[8227]: added connection description "BT"<br>Oct 19 16:23:36 localhost pluto[8227]: listening for IKE messages<br>Oct 19 16:23:36 localhost pluto[8227]: adding interface ipsec0/eth0
213.30.xxx.xxx<br>Oct 19 16:23:36 localhost pluto[8227]: loading secrets from "/etc/ipsec.secrets"<br>Oct 19 16:23:36 localhost pluto[8227]: loaded private key file '/etc/ipsec.d/private/karlmarxKey.pem' (1679 bytes)
<br>Oct 19 16:23:36 localhost pluto[8227]: "BT" #1: initiating Main Mode<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring Vendor ID payload [XAUTH]
<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: received Vendor ID payload [Dead Peer Detection]<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring Vendor ID payload [Cisco-Unity]<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring Vendor ID payload [03d6443be45f8cd79702d5e5a384f2c9]
<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: I did not send a certificate because I do not have one.<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: Peer ID is ID_IPV4_ADDR: '217.34.yyy.yyy'<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ISAKMP SA established<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #2: initiating Quick Mode PSK+ENCRYPT+COMPRESS+TUNNEL+UP {using isakmp#1}<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: received and ignored informational message<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
<br>Oct 19 16:23:37 localhost pluto[8227]: "BT" #1: received and ignored informational message<br>Oct 19 16:23:47 localhost pluto[8227]: packet from 217.34.yyy.yyy:500: not enough room in input packet for ISAKMP Message
<br>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<br>Oct 19 16:23:52 localhost pluto[8227]: packet from 217.34.yyy.yyy:500: not enough room in input packet for ISAKMP Message
<br>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<br>Oct 19 16:23:57 localhost pluto[8227]: packet from 217.34.yyy.yyy:500: not enough room in input packet for ISAKMP Message
<br>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<br><br><br>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.
<br>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.<br><br>But it seems that I found sort of a problem already seen, related either to the distant subnet, or the cisco policies.
<br><br>So here are my questions :<br><br>Did you heard about such a problem?<br>Did you know how to implement specific security policy with openswan related to a tunnel?<br>Did you know how/if a security policies declared on cisco could influence the phase2 negociation?
<br><br>My configuration :<br><br>conn BT<br> authby=secret<br> type=tunnel<br> auto=start<br> compress=yes<br> pfs=no<br> keyexchange=ike<br> esp="3des-sha1-96"<br>
ikelifetime=28800<br> #ike="3des-sha1"<br> # Left security gateway, subnet behind it, next hop toward right.<br> left=213.30.xxx.xxx<br> leftsubnet=213.30.xxx.aaa/32<br> leftnexthop=
213.30.xxx.bbb<br> # Right security gateway, subnet behind it, next hop toward left.<br> right=217.34.yyy.yyy<br> rightsubnet=217.41.zzz.zzz/31<br><br>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
<br><br>Many thanks,<br>Jean-Michel<br></span><b><span class="nw" id="_user_users@openswan.org"><br></span></b>