[Openswan Users] No VPN from FC3 client to Sentinel (?) server

Christian Brechbühler brechbuehler at gmail.com
Wed Feb 15 21:34:57 CET 2006


Hi Davide,

What you see looks exactly like the symptoms I get.  The corresponding
log on the server side shows all going well including ISAKMP setup,
then it fails:

    [pluto] "home-l2tp-newwin"[1] 2.2.2.2 #3: STATE_MAIN_R3: sent MR3,
ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
    [pluto] "home-l2tp-newwin"[1] 2.2.2.2 #3: cannot respond to IPsec
SA request because no connection is known for 6.6.6.6[C=US,
ST=Massachusetts, L=Boston, O=E..., CN=l...,
E=brechbuehler at gmail.com]:17/1701...2.2.2.2[@IBM-A242175E87C]:17/1701
    [pluto] "home-l2tp-newwin"[1] 2.2.2.2 #3: sending encrypted
notification INVALID_ID_INFORMATION to 2.2.2.2:48336

(2.2.2.2 is the client, 6.6.6.6 is the server.)  That
INVALID_ID_INFORMATION is exactly what your client receives.  I
haven't figured out yet what's wrong in the above case (Windows XP
client).  It could be wrong id, subnet, subnetwithin ...?  When the
client ("left") was Openswan on Linux, I added

    leftsubnetwithin=192.168.2.0/24

to the ipsec.conf on the server ("right");  (I feel that I shouldn't
have to tell that to the server for a roadwarrior, but) it fixed the
problem.

Bottom line is the server decided not to let your client connect,
because it has no matching connection.

Good luck

    Christian

On 2/15/06, Davide Bolcioni <db-ipsec at 3di.it> wrote:
> Greetings,
> please discard my previous message.
>
> I am attempting to setup a VPN between Fedora Core 3
> openswan-2.4.4-0.FC3.1 and a (supposedly) Sentinel server.
>
> I was supplied with a configuration which ought to work, but
> my problem is that, after ISAKMP setup, initiation fails:
>
>
> [root at host ~]# ipsec auto --up c
> 104 "c" #1: STATE_MAIN_I1: initiate
> 003 "c" #1: received Vendor ID payload [Openswan (this version) 2.4.4
> X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
> 003 "c" #1: received Vendor ID payload [Dead Peer Detection]
> 003 "c" #1: received Vendor ID payload [RFC 3947] method set to=109
> 106 "c" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> 003 "c" #1: NAT-Traversal: Result using 3: i am NATed
> 108 "c" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "c" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG
> cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
> 117 "c" #2: STATE_QUICK_I1: initiate
> 010 "c" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
> 010 "c" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
> 031 "c" #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 "c" #2: starting keying attempt 2 of an unlimited number, but
> releasing whack
>
> A look in /var/log/debug brought my attention to this:
>
> host pluto[7495]: | received encrypted packet from 81.208.39.130:4500
> host pluto[7495]: | decrypting 32 bytes using algorithm OAKLEY_3DES_CBC
> host pluto[7495]: | decrypted:
> ...
> host pluto[7495]: | ***parse ISAKMP Hash Payload:
> host pluto[7495]: |    next payload type: ISAKMP_NEXT_N
> host pluto[7495]: |    length: 20
> host pluto[7495]: | ***parse ISAKMP Notification Payload:
> host pluto[7495]: |    next payload type: ISAKMP_NEXT_NONE
> host pluto[7495]: |    length: 12
> host pluto[7495]: |    DOI: ISAKMP_DOI_IPSEC
> host pluto[7495]: |    protocol ID: 1
> host pluto[7495]: |    SPI size: 0
> host pluto[7495]: |    Notify Message Type: INVALID_ID_INFORMATION
> host pluto[7495]: "c" #1: ignoring informational payload, type
> INVALID_ID_INFORMATION
> host pluto[7495]: | info:
> host pluto[7495]: | processing informational INVALID_ID_INFORMATION (18)
> host pluto[7495]: "c" #1: received and ignored informational message
> host pluto[7495]: | complete state transition with STF_IGNORE
>
> but I cannot tell if this is significant, my only clue is that it seems
> to give up at this point, and what the problem may be. I verified that
> my firewall, the one doing the NAT, is not stopping any packet going
> to the sentinel IP, just in case.
>
> Thank you for your consideration
> --
> Paranoia is an afterthought.
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>


More information about the Users mailing list