Re: [strongSwan] received TS_UNACCEPTABLE notify, no CHILD_SA built

Fri, 09 Feb 2018 11:08:45 -0800

Can  you send the logs from the other side? the one that generates the TS_UNACCEPTABLE notify. 

--Jafar

On 2/9/2018 12:31 AM, Sujoy wrote:


Hi Jafar/Noel,
What means " received TS_UNACCEPTABLE notify, no CHILD_SA built [IKE] failed to establish CHILD_SA, keeping IKE_SA" . Same error comes in the new installed Linux also. 


root@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(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] 
sending packet: from 192.168.10.38[500] to 192.168.10.40[500] (464 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{1}
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) N(MSG_ID_SYN_SUP) ] sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (368 bytes) received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (160 bytes) parsed IKE_AUTH response 1 [ IDr AUTH 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 rekeying in 2642s
maximum IKE_SA lifetime 3182s
received TS_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA
peer supports MOBIKE
establishing connection 'tunnel' failed
Feb  9 11:55:44 localhost charon: 14[NET] sending packet: from 192.168.10.38[4500] to 192.168.10.40[4500] (368 bytes) Feb  9 11:55:44 localhost charon: 16[NET] received packet: from 192.168.10.40[4500] to 192.168.10.38[4500] (160 bytes) Feb  9 11:55:44 localhost charon: 16[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) N(TS_UNACCEPT) ] Feb  9 11:55:44 localhost charon: 16[IKE] authentication of '192.168.10.40' with pre-shared key successful Feb  9 11:55:44 localhost charon: 16[IKE] IKE_SA tunnel[1] established between 192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40] 
Feb  9 11:55:44 localhost charon: 16[IKE] scheduling rekeying in 2642s
Feb  9 11:55:44 localhost charon: 16[IKE] maximum IKE_SA lifetime 3182s
*Feb  9 11:55:44 localhost charon: 16[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built** **Feb  9 11:55:44 localhost charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA* 
Feb  9 11:55:44 localhost charon: 16[IKE] peer supports MOBIKE


Thanks
On Friday 09 February 2018 11:21 AM, Sujoy wrote:
Thanks Jafar, for the update. But after setting up without subnet and "type=tunnel or transport" it shows the same error "failed to establish CHILD_SA, keeping IKE_SA. What should be issue. 


Thanks

On Friday 09 February 2018 01:53 AM, Jafar Al-Gharaibeh wrote:

Sujoy,

  Just to make sure everything is working OK. Try setting:

        left=192.168.10.40
        right=192.168.10.38

and

        left=192.168.10.38
        right=192.168.10.40
Comment out left/rightsubnet configs. They should default to the same IP addresses as left/right. 

--Jafar


On 2/8/2018 12:26 AM, Sujoy wrote:
Hi Jafar,    Peer is also using strongswan 5.3.3. following is the configuration. We need tunnel because once it is connected in LAN we want to implement in WAN/Internet. Output of the 192.168.10.40 is bellow. 

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

root@server:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.3.3, Linux 4.4.0-112-generic, x86_64): 
  uptime: 114 minutes, since Feb 08 09:58:49 2018
  malloc: sbrk 2703360, mmap 0, used 513168, free 2190192
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 5   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.40
  10.8.0.1
Connections:
      tunnel:  %any...192.168.10.38  IKEv2, dpddelay=30s
      tunnel:   local:  uses pre-shared key authentication
      tunnel:   remote: [192.168.10.38] uses pre-shared key authentication       tunnel:   child:  dynamic === 192.168.10.0/24 TUNNEL, dpdaction=restart 
Security Associations (1 up, 0 connecting):
      tunnel[3]: ESTABLISHED 25 minutes ago, 192.168.10.40[192.168.10.40]...192.168.10.38[192.168.10.38]       tunnel[3]: IKEv2 SPIs: c1a42433ade9fa28_i a52cfea6d767c397_r*, pre-shared key reauthentication in 24 minutes       tunnel[3]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 



Thanks

On Wednesday 07 February 2018 09:06 PM, Jafar Al-Gharaibeh wrote:



On 2/7/2018 9:22 AM, Sujoy wrote:
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"
"TS_UNACCEPTABLE notify"  means the peer didn't like the proposed traffic selector.  The log shows that your IKE SA is up, so you don't have a problem there. I can't tell you what your rightsubnet should be unless you tell us more about the setup you have. What is your peer running? is it also strongSwan?
If you only want to encrypt traffic from  192.168.10.38 to 192.168.10.40 and you don't have other subnets/hosts, you can switch the connection type to transport mode ("type=trasnport"). Both sides must agree on this. transport doesn't require left/rightsubnets. 

--Jafar



   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@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@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@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@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.

Reply via email to