[strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

Sujoy sujoy.b at mindlogicx.com
Wed Feb 7 16:22:36 CET 2018


Thanks Jafar, for the reply. But after removing subnet from the config 
also tunneling failed. Is there any issue with the version of strongswan 
5.3.3. What means "TS_UNACCEPTABLE notify, no CHILD_SA built"


    Config setup

         charondebug="all"
         uniqueids=yes
         strictcrlpolicy=yes
conn %default
conn tunnel #
         left=%any
         right=192.168.10.40
         ike=aes256-sha1-modp2048!
         esp=aes256-sha1-modp2048!
         keyingtries=1
         ikelifetime=1h
         lifetime=8h
         dpddelay=30
         #dpdtimeout=120
         dpdaction=restart
         authby=secret
         auto=route
         keyexchange=ikev2
         type=tunnel


root at client:~# ipsec up tunnel
initiating IKE_SA tunnel[1] to 192.168.10.40
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) ]
sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (448 bytes)
received packet: from 192.168.10.40[500] to 192.168.10.38[500] (456 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(HASH_ALG) N(MULT_AUTH) ]
remote host is behind NAT
no IDi configured, fall back on IP address
authentication of '192.168.10.38' (myself) with pre-shared key
establishing CHILD_SA tunnel
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr 
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) 
N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) 
N(EAP_ONLY) ]
sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (348 bytes)
received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (156 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) 
N(ADD_4_ADDR) N(TS_UNACCEPT) ]
authentication of '192.168.10.40' with pre-shared key successful
IKE_SA tunnel[1] established between 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]
scheduling reauthentication in 2819s
maximum IKE_SA lifetime 3359s
*received TS_UNACCEPTABLE notify, no CHILD_SA built**
**failed to establish CHILD_SA, keeping IKE_SA*
received AUTH_LIFETIME of 2637s, scheduling reauthentication in 2097s
peer supports MOBIKE
establishing connection 'tunnel' failed


root at client:~# ipsec statusall
Status of IKE charon daemon *(strongSwan 5.3.3, Linux 4.4.0-112-generic, 
x86_64)*:
   uptime: 2 minutes, since Feb 07 20:44:23 2018
   malloc: sbrk 2703360, mmap 0, used 519600, free 2183760
   worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, 
scheduled: 4
   loaded plugins: charon aes kernel-libipsec des rc2 sha1 sha2 md5 
random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 
pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac curl attr 
kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
   192.168.10.38
   192.168.3.107

Connections:
       tunnel:  %any...192.168.10.40  IKEv2, dpddelay=30s
       tunnel:   local:  uses pre-shared key authentication
       tunnel:   remote: [192.168.10.40] uses pre-shared key authentication
       tunnel:   child:  dynamic === dynamic TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
       tunnel[1]: ESTABLISHED 2 minutes ago, 
192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]
       tunnel[1]: IKEv2 SPIs: 175dcf9cdcf11b38_i* 9cc05896738a5e45_r, 
pre-shared key reauthentication in 32 minutes
       tunnel[1]: IKE proposal: 
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

Thanks

On Wednesday 07 February 2018 08:31 PM, Jafar Al-Gharaibeh wrote:
> Sujoy,
>
>   Are you sure about
>
>    rightsubnet=192.168.10.0/32
>
>  This subnet gets you nothing unless you know that it has a special 
> meaning in the config that I'm not aware of. You can have the least 
> significant octet set to zero with a 32-bit netmask. What is the 
> rightsubnet that you are trying to protect? is it all 192.168.10.0/24? 
> or just  one host like  192.168.10.100?
>
> --Jafar
>
>
>
> On 2/7/2018 12:44 AM, Sujoy wrote:
>>
>> Hi Noel,
>>
>> Still cannot establish tunnel. logs doesn't show anything. Can 
>> someone help to solve this.
>>
>> Client configuration
>>
>> config setup
>>
>>         charondebug="all"
>>         uniqueids=yes
>>         strictcrlpolicy=no
>> conn %default
>> conn tunnel #
>>         left=%any
>>         right=192.168.10.40
>>         rightsubnet=192.168.10.0/32
>>         ike=aes128-md5-modp1536
>>         esp=aes128-sha1
>>         keyingtries=%forever
>>         ikelifetime=1h
>>         lifetime=8h
>>         dpddelay=30
>>         #dpdtimeout=120
>>         #dpdaction=restart
>>         authby=secret
>>         auto=start
>>         keyexchange=ikev2
>>         type=tunnel
>>         mobike=no
>>         #pfs=no
>>         reauth=no
>>
>> Server setup
>>
>> config setup
>>
>>         charondebug="all"
>>         uniqueids=yes
>>         strictcrlpolicy=no
>> conn %default
>> conn tunnel #conn %default
>> conn tunnel #
>>         left=%any
>>         right=192.168.10.40
>>         rightsubnet=192.168.10.0/32
>>         ike=aes128-md5-modp1536
>>         esp=aes128-sha1
>>         keyingtries=%forever
>>         ikelifetime=1h
>>         lifetime=8h
>>         dpddelay=30
>>         #dpdtimeout=120
>>         #dpdaction=restart
>>         authby=secret
>>         auto=start
>>         keyexchange=ikev2
>>         type=tunnel
>>         mobike=no
>>         #pfs=no
>>         reauth=no
>>
>>
>> root at client:~# *ipsec up tunnel*
>> initiating IKE_SA tunnel[2] to 192.168.10.40
>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
>> N(HASH_ALG) ]
>> sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (1064 
>> bytes)
>> received packet: from 192.168.10.40[500] to 192.168.10.38[500] (38 bytes)
>> parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
>> peer didn't accept DH group MODP_2048, it requested MODP_1536
>> initiating IKE_SA tunnel[2] to 192.168.10.40
>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
>> N(HASH_ALG) ]
>> sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (1000 
>> bytes)
>> received packet: from 192.168.10.40[500] to 192.168.10.38[500] (392 
>> bytes)
>> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
>> N(HASH_ALG) N(MULT_AUTH) ]
>> remote host is behind NAT
>> no IDi configured, fall back on IP address
>> authentication of '192.168.10.38' (myself) with pre-shared key
>> establishing CHILD_SA tunnel
>> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi 
>> TSr N(MULT_AUTH) N(EAP_ONLY) ]
>> sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (332 
>> bytes)
>> received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (108 
>> bytes)
>> parsed IKE_AUTH response 1 [ IDr AUTH N(TS_UNACCEPT) ]
>> authentication of '192.168.10.40' with pre-shared key successful
>> IKE_SA tunnel[2] established between 
>> 192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]
>> scheduling rekeying in 2525s
>> maximum IKE_SA lifetime 3065s
>> *received TS_UNACCEPTABLE notify, no CHILD_SA built**
>> **failed to establish CHILD_SA, keeping IKE_SA**
>> **establishing connection 'tunnel' failed*
>> root at client:~#
>>
>>
>> Ipsec statusall
>>
>> Status of IKE charon daemon (*strongSwan 5.3.3, Linux 
>> 4.4.0-112-generic, x86_64*):
>>   uptime: 41 seconds, since Feb 07 12:08:32 2018
>>   malloc: sbrk 2703360, mmap 0, used 519216, free 2184144
>>   worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, 
>> scheduled: 2
>>   loaded plugins: charon aes kernel-libipsec des rc2 sha1 sha2 md5 
>> random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 
>> pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac curl 
>> attr kernel-netlink resolve socket-default stroke updown xauth-generic
>> Listening IP addresses:
>>   192.168.10.38
>>   192.168.3.107
>>
>> Connections:
>>       tunnel:  %any...192.168.10.40  IKEv2
>>       tunnel:   local:  uses pre-shared key authentication
>>       tunnel:   remote: [192.168.10.40] uses pre-shared key 
>> authentication
>>       tunnel:   child:  dynamic === 192.168.10.0/32 TUNNEL
>> Security Associations (1 up, 0 connecting):
>>       tunnel[1]: ESTABLISHED 41 seconds ago, 
>> 192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]
>>       tunnel[1]: IKEv2 SPIs: 53b251675b863a7d_i* 57d33cd8149f729f_r, 
>> rekeying in 41 minutes
>>       tunnel[1]: IKE proposal: 
>> AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
>>
>>
>> On Tuesday 16 January 2018 11:23 PM, Noel Kuntze wrote:
>>> Hi,
>>>
>>> Check the logs of the remote side.
>>> It means the remote peer did not like the proposed traffic selector. It was probably outside of the network range that its own configuration allows, meaning narrowing failed.
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>>
>>> On 16.01.2018 07:25, Sujoy wrote:
>>>> Hi Noel,
>>>>
>>>> Same strongswan 5.3.3 configuration working in my VM(client) to desktop server. But not working from my OpenWRT to Global IP used nated Linux server. Can you help me to solve this.
>>>>
>>>> what means "received TS_UNACCEPTABLE notify, no CHILD_SA built"
>>>>
>>>> Server config file.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks & Regards
>>>>
>>>> Sujoy
>>>>
>>>> On Thursday 04 January 2018 03:38 AM, Noel Kuntze wrote:
>>>>> Hi,
>>>>>
>>>>> Only on the responder.
>>>>> If you use dpd and enforce UDP encapsulation, you do not need to open any ports on the initiator side.
>>>>> Refer to the UsableExamples wiki page[1] for example configurations that are usable in the real world.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Noel
>>>>>
>>>>> [1]https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>>>>>
>>>>> On 28.12.2017 08:51, Sujoy wrote:
>>>>>> Hi All,
>>>>>>
>>>>>>
>>>>>> We want to implement StrongSwan,with IPsec in OpenWRT. IPSec server will be running in CentOS and the OpenWRt router will connect to it using VPN. I have configured the server part, struggling to configure the client part. Do we need to open port 4500 for this first.
>>>>>>
>>>>>> Anyone can suggest any solution for this.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180207/fe28bc5b/attachment-0001.html>


More information about the Users mailing list