[Openswan Users] cannot respond to IPsec SA request because no connection is known for

janantha at techcert.lk janantha at techcert.lk
Fri Mar 20 04:53:08 EDT 2009 

Yes indeed.. I've just checked and see no encryption been implemented.  
So my problem is still not Over!

:)

Quoting "Catalin Sanda" <catalin.sanda at gmail.com>:

> Hello,
>
> According to
> http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/87671.mspx?mfr=true,
> the registry setting disables IPSec altogether and your l2tp connections
> will not be secured. Of course you can use encryption at pptp level, but
> this is considered very weak compared to ipsec.
>
> Catalin
>
> On Fri, Mar 20, 2009 at 9:27 AM, Janantha Marasinghe
> <janantha at techcert.lk>wrote:
>
>>  Thank Saso..
>>
>> Works perfectly now.!!
>>
>> Saso Tavcar wrote:
>>
>> Hi!
>>
>> I had the same problem also with latest development packages for xl2tpd and
>> openswan.
>> PPP session does not start with L2TP+IPsec+PSK client configuration!?
>>
>> Try with disabled IPsec on Windows XP client.
>>
>> Run this registry settings and reboot your Windows XP client:
>>
>> Windows Registry Editor Version 5.00
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]
>> "prohibitipsec"=dword:00000001
>>
>>
>> Regards,
>> saso
>>
>>
>> On Mar 20, 2009, at 3:50 AM, Janantha Marasinghe wrote:
>>
>> Hello,
>>
>> Yes all my clients are Windows XP (Sp3) . I do use xl2tpd for the tunnel.
>> The configuration of xl2tpd is
>>
>> [global]
>> [lns default]
>> ip range = 10.8.109.100-10.8.109.110
>> local ip = 10.8.109.65
>> require chap = yes
>> refuse pap = yes
>> require authentication = yes
>> name = LinuxVPNServer
>> ppp debug = yes
>> pppoptfile = /etc/ppp/options.xl2tpd
>> length bit = yes
>>
>> If this doesn't work I'll upgrade the current openswan as well( I see an
>> update for it for my FC9). Other
>>
>> Catalin Sanda wrote:
>>
>>
>> Hello,
>>
>> >From what I can gather, you are trying to use a windows 2000+ client to
>> connect to your Linux box. Ipsec seems to work, so now you have to setup
>> the
>> l2tp tunel (i personaly use xl2tp).
>>
>> Unfortunately the setup you are trying to achieve didn't work for me
>> because
>> of a bug in openswan (see the response to one of my earlier posts), so i
>> had
>> to switch to strongswan which worked.
>>
>> Hope this helps,
>> Catalin
>>
>>
>> On Thu, Mar 19, 2009 at 12:52 PM, Janantha Marasinghe
>> <janantha at techcert.lk> <janantha at techcert.lk>wrote:
>>
>>
>>  Hi Catalin,
>>
>> Thanks your suggestions. I amended as you stated and now it does go to
>> state 2. . But after it gets stuck on the following line written at
>> /var/log/secure
>>
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x38511bd7
>> <0xd834470c xfrm=3DES_0-HMAC_MD5 NATOA=172.16.0.9
>> NATD=roadwarrior-routerip:4500 DPD=none}
>>
>> My windows clients give the 678 error message. Do I have to change my ADSL
>> router firewall configuration? Rest of the transitions are below
>>
>> Mar 19 16:16:00 mooshika pluto[32010]: packet from
>> roadwarrior-routerip:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY
>> 00000004]
>> Mar 19 16:16:00 mooshika pluto[32010]: packet from
>> roadwarrior-routerip:500: ignoring Vendor ID payload [FRAGMENTATION]
>> Mar 19 16:16:00 mooshika pluto[32010]: packet from
>> roadwarrior-routerip:500: received Vendor ID payload
>> [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
>> Mar 19 16:16:00 mooshika pluto[32010]: packet from
>> roadwarrior-routerip:500: ignoring Vendor ID payload [Vid-Initial-Contact]
>> Mar 19 16:16:00 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: responding to Main Mode from unknown peer roadwarrior-routerip
>>
>>
>>  Mar 19 16:16:00 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>>
>> #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
>> Mar 19 16:16:00 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: STATE_MAIN_R1: sent MR1, expecting MI2
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is
>> NATed
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: STATE_MAIN_R2: sent MR2, expecting MI3
>> Mar 19 16:16:01 mooshika pluto[32013]: WARNING: calc_dh_shared(): for
>> OAKLEY_GROUP_MODP2048 took 228522 usec
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: Main mode peer ID is ID_FQDN: '@techcert-37a9ea'
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: new NAT mapping for #5, was roadwarrior-routerip:500, now
>> roadwarrior-routerip:4500
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established
>> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
>> group=modp2048}
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: peer client type is FQDN
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: Applying workaround for MS-818043 NAT-T bug
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: IDci was FQDN: \300\370\010k, using NAT_OA=172.16.0.9/32 as IDci
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: the peer proposed: vpn.server.ip/32:17/1701 -> 172.16.0.9/32:17/1701
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in
>>
>> duplicate_state, please report to dev at openswan.org
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in
>>
>> duplicate_state, please report to dev at openswan.org
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in
>>
>> duplicate_state, please report to dev at openswan.org
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in
>>
>> duplicate_state, please report to dev at openswan.org
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6: responding to Quick Mode proposal {msgid:c1ca4ad8}
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6:     us: vpn.server.ip<vpn.server.ip>[+S=C]:17/1701
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6:   them: roadwarrior-routerip[@techcert-37a9ea,+S=C]:17/1701===
>> 172.16.0.9/32
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
>> Mar 19 16:16:01 mooshika pluto[32010]: "L2TP-PSK"[2] roadwarrior-routerip
>> #6: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x38511bd7
>> <0xd834470c xfrm=3DES_0-HMAC_MD5 NATOA=172.16.0.9
>> NATD=roadwarrior-routerip:4500 DPD=none}
>>
>>
>>
>> Catalin Sanda wrote:
>>
>> It might help if you have something like:
>>
>> config setup
>>         #......
>>         nat_traversal=yes
>>         virtual_private=%v4:
>> 10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
>>
>> conn L2TP-PSK
>>        #.......
>>        rightsubnet=vhost:%no,%priv
>>
>>
>>
>> On Thu, Mar 19, 2009 at 10:09 AM, Janantha Marasinghe
>> <janantha at techcert.lk> <janantha at techcert.lk>  
>> <janantha at techcert.lk><janantha at techcert.lk>wrote:
>>
>>
>>
>>
>>   Thanks Andrew,
>>
>> I have included nat_traversal=yes in the ipsec.conf and restarted the
>> services but still the same!
>>
>>
>>
>> andrew colin wrote:
>>
>> I think you do not have nat traversal enabled that is why.
>>
>> On Thu, Mar 19, 2009 at 5:54 AM, Janantha  
>> Marasinghe<janantha at techcert.lk><janantha at techcert.lk>
>> <janantha at techcert.lk> <janantha at techcert.lk>  
>> <janantha at techcert.lk><janantha at techcert.lk>
>> <janantha at techcert.lk> <janantha at techcert.lk> wrote:
>>
>>
>>  Dear All,
>>
>> Currently I'm trying to connect to my openswan server.  My network setup
>> is given below. When I try to connect using a fully up to date SP3
>> Windows XP system .. I see the following error in the vpn server's
>> secure log
>>
>> Mar 19 09:06:02 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: cannot respond to IPsec SA request because no
>> connection is known for
>>
>> vpn.server.ip<vpn.server.ip>[+S=C]:17/1701...roadwarrior-routerip[@computername-37a9ea,+S=C]:17/1701===
>> 172.16.0.9/32
>>
>> Mar 19 09:06:02 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: sending encrypted notification
>> INVALID_ID_INFORMATION to roadwarrior-routerip:4500
>> Mar 19 09:06:03 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: peer client type is FQDN
>> Mar 19 09:06:03 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: Applying workaround for MS-818043 NAT-T bug
>> Mar 19 09:06:03 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: IDci was FQDN: \300\370\010k, using
>> NAT_OA=172.16.0.9/32 as IDci
>> Mar 19 09:06:03 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: the peer proposed: vpn.server.ip/32:17/1701 ->
>> 172.16.0.9/32:17/1701
>> Mar 19 09:06:03 mooshika pluto[18623]: "L2TP-PSK"[4]
>> roadwarrior-routerip #2: cannot respond to IPsec SA request because no
>> connection is known for
>>
>> vpn.server.ip<vpn.server.ip>[+S=C]:17/1701...roadwarrior-routerip[@computer-37a9ea,+S=C]:17/1701===
>> 172.16.0.9/32
>>
>>
>>
>>  private network172.16.0.0/255.255.255.240 --> ADSL Router(NAT enabled)
>> ---------Internet--------------OpenswanVPN(Public IP Address)
>>
>> My IPsec.conf is
>>
>> # /etc/ipsec.conf - Openswan IPsec configuration file
>> #
>> # Manual:     ipsec.conf.5
>> #
>> # Please place your own config files in /etc/ipsec.d/ ending in .conf
>>
>> version 2.0     # conforms to second version of ipsec.conf specification
>>
>> # basic configuration
>> config setup
>>        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
>>
>>        # klipsdebug=none
>>        # plutodebug="control parsing"
>>        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
>>        protostack=netkey
>>
>> conn L2TP-PSK
>>        #
>>        authby=secret
>>        pfs=no
>>        rekey=no
>>        keyingtries=3
>>        #
>>        # ----------------------------------------------------------
>>        # The VPN server.
>>        #
>>        # Allow incoming connections on the external network interface.
>>        # If you want to use a different interface or if there is no
>>        # defaultroute, you can use:   left=your.ip.addr.ess
>>        #
>>        left=public.ip.address.of.vpn.server
>>        #
>>        leftprotoport=17/1701
>>        # If you insist on supporting non-updated Windows clients,
>>        # you can use:    leftprotoport=17/%any
>>        #
>>        # ----------------------------------------------------------
>>        # The remote user(s).
>>        #
>>        # Allow incoming connections only from this IP address.
>>        right=%any
>>        # If you want to allow multiple connections from any IP address,
>>        # you can use:    right=%any
>>        #
>>        rightprotoport=17/1701
>>        #
>>        # ----------------------------------------------------------
>>        # Change 'ignore' to 'add' to enable this configuration.
>>        #
>>        auto=add
>>
>> include /etc/ipsec.d/no_oe.conf
>>
>> Do I have to put additional information in the ipsec.conf to include
>> 172.16.0.0./255.255.255.240 ?
>>
>> --
>>
>> _______________________________________________Users at openswan.orghttp://
>> 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
>>
>>
>> --
>>
>>
>> _______________________________________________Users at openswan.orghttp://
>> 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
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>> --
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> --
>>
>> _______________________________________________
>> 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
>>
>>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

More information about the Users mailing list