<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Sujoy,<br>
    <br>
         The responder  (at 192.168.10.40) thinks the initiator
    (192.168.10.38) is proposing 192.168.122.153/32 as  traffic
    selector. Where is 192.168.122.153 coming from?<br>
    <br>
    --Jafar  <br>
    <br>
    <div class="moz-cite-prefix">On 2/12/2018 7:34 AM, Sujoy wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9c8b347b-2800-69eb-7e22-8b49b329f679@mindlogicx.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>Hi Jafar,<br>
      </p>
      <p>Following is the logs and configuration of the other node.
        Cannot solve this issue for last thirty days.  <br>
      </p>
      <p><br>
      </p>
      <p><img src="cid:part1.92FC68EB.781BF676@atcorp.com" alt=""
          class="" height="662" width="1378"></p>
      <div class="moz-signature"><br>
        Config setup<br>
        <img src="cid:part2.C2806BEE.096C3076@atcorp.com" alt=""
          class=""><br>
        <br>
        ipsec.Secrets<br>
        <br>
        : PSK "abc123"<br>
        <br>
        <br>
        <br>
      </div>
      <div class="moz-cite-prefix">On Saturday 10 February 2018 12:38
        AM, Jafar Al-Gharaibeh wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:38b6a698-0b07-57f2-b1ef-cb50b7fc17a1@atcorp.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        Can  you send the logs from the other side? the one that
        generates  the TS_UNACCEPTABLE notify.<br>
        <br>
        --Jafar<br>
        <br>
        <div class="moz-cite-prefix">On 2/9/2018 12:31 AM, Sujoy wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:222b6609-6ba5-0147-2076-0dafdcf09160@mindlogicx.com">
          <meta http-equiv="Content-Type" content="text/html;
            charset=utf-8">
          <p>Hi Jafar/Noel, <br>
          </p>
          <p>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. <br>
          </p>
          <p><br>
          </p>
          <p>root@client:~# ipsec up tunnel<br>
            initiating IKE_SA tunnel[1] to 192.168.10.40<br>
            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) ]<br>
            sending packet: from 192.168.10.38[500] to
            192.168.10.40[500] (464 bytes)<br>
            received packet: from 192.168.10.40[500] to
            192.168.10.38[500] (456 bytes)<br>
            parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
            N(NATD_D_IP) N(HASH_ALG) N(MULT_AUTH) ]<br>
            remote host is behind NAT<br>
            no IDi configured, fall back on IP address<br>
            authentication of '192.168.10.38' (myself) with pre-shared
            key<br>
            establishing CHILD_SA tunnel{1}<br>
            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) ]<br>
            sending packet: from 192.168.10.38[4500] to
            192.168.10.40[4500] (368 bytes)<br>
            received packet: from 192.168.10.40[4500] to
            192.168.10.38[4500] (160 bytes)<br>
            parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP)
            N(ADD_4_ADDR) N(TS_UNACCEPT) ]<br>
            authentication of '192.168.10.40' with pre-shared key
            successful<br>
            IKE_SA tunnel[1] established between
            192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]<br>
            scheduling rekeying in 2642s<br>
            maximum IKE_SA lifetime 3182s<br>
            received TS_UNACCEPTABLE notify, no CHILD_SA built<br>
            failed to establish CHILD_SA, keeping IKE_SA<br>
            peer supports MOBIKE<br>
            establishing connection 'tunnel' failed<br>
            <br>
          </p>
          <p><br>
          </p>
          <div class="moz-signature"><br>
            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)<br>
            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)<br>
            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) ]<br>
            Feb  9 11:55:44 localhost charon: 16[IKE] authentication of
            '192.168.10.40' with pre-shared key successful<br>
            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]<br>
            Feb  9 11:55:44 localhost charon: 16[IKE] scheduling
            rekeying in 2642s<br>
            Feb  9 11:55:44 localhost charon: 16[IKE] maximum IKE_SA
            lifetime 3182s<br>
            <b>Feb  9 11:55:44 localhost charon: 16[IKE] received
              TS_UNACCEPTABLE notify, no CHILD_SA built</b><b><br>
            </b><b>Feb  9 11:55:44 localhost charon: 16[IKE] failed to
              establish CHILD_SA, keeping IKE_SA</b><br>
            Feb  9 11:55:44 localhost charon: 16[IKE] peer supports
            MOBIKE<br>
                                                                <br>
            <br>
            Thanks</div>
          <div class="moz-cite-prefix">On Friday 09 February 2018 11:21
            AM, Sujoy wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:b0bdab0b-78f5-3841-fd74-360f5dd62d83@mindlogicx.com">
            <meta http-equiv="Content-Type" content="text/html;
              charset=utf-8">
            <p>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. <br>
            </p>
            <p><img src="cid:part3.80893930.2B2AD4DA@atcorp.com" alt=""
                class="">                   <img
                src="cid:part4.869829CE.E1969FE2@atcorp.com" alt=""
                class="" height="223" width="733"></p>
            <div class="moz-signature"><br>
              Thanks <br>
              <br>
            </div>
            <div class="moz-cite-prefix">On Friday 09 February 2018
              01:53 AM, Jafar Al-Gharaibeh wrote:<br>
            </div>
            <blockquote type="cite"
              cite="mid:d678256e-0513-d601-5837-9a9b98b68f1a@atcorp.com">
              <meta http-equiv="Content-Type" content="text/html;
                charset=utf-8">
              Sujoy,<br>
              <br>
                Just to make sure everything is working OK. Try setting:<br>
              <br>
                      left=192.168.10.40<br>
                      right=192.168.10.38<br>
              <br>
              and <br>
              <br>
                      left=192.168.10.38<br>
                      right=192.168.10.40<br>
              <br>
              Comment out left/rightsubnet configs. They should default
              to the same IP addresses as left/right.<br>
              <br>
              --Jafar<br>
               <br>
              <br>
              <div class="moz-cite-prefix">On 2/8/2018 12:26 AM, Sujoy
                wrote:<br>
              </div>
              <blockquote type="cite"
                cite="mid:24a9deac-1dd5-49c1-e7f3-feb6bd5f6357@mindlogicx.com">
                <meta http-equiv="Content-Type" content="text/html;
                  charset=utf-8">
                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. <br>
                <br>
                    Config setup<br>
                        charondebug="all"<br>
                        uniqueids=yes<br>
                        strictcrlpolicy=yes<br>
                conn %default<br>
                conn tunnel #<br>
                        left=%any<br>
                        right=192.168.10.38<br>
                        rightsubnet=192.168.10.38/24<br>
                        ike=aes256-sha1-modp2048!<br>
                        esp=aes256-sha1-modp2048!<br>
                        keyingtries=1<br>
                        ikelifetime=1h<br>
                        lifetime=8h<br>
                        dpddelay=30<br>
                        #dpdtimeout=120<br>
                        dpdaction=restart<br>
                        authby=psk<br>
                        auto=route<br>
                        keyexchange=ikev2<br>
                        type=tunnel<br>
                <br>
                <p>root@server:~# ipsec statusall<br>
                  Status of IKE charon daemon (strongSwan 5.3.3, Linux
                  4.4.0-112-generic, x86_64):<br>
                    uptime: 114 minutes, since Feb 08 09:58:49 2018<br>
                    malloc: sbrk 2703360, mmap 0, used 513168, free
                  2190192<br>
                    worker threads: 7 of 16 idle, 5/0/4/0 working, job
                  queue: 0/0/0/0, scheduled: 5<br>
                    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<br>
                  Listening IP addresses:<br>
                    192.168.10.40<br>
                    10.8.0.1<br>
                  Connections:<br>
                        tunnel:  %any...192.168.10.38  IKEv2,
                  dpddelay=30s<br>
                        tunnel:   local:  uses pre-shared key
                  authentication<br>
                        tunnel:   remote: [192.168.10.38] uses
                  pre-shared key authentication<br>
                        tunnel:   child:  dynamic === 192.168.10.0/24
                  TUNNEL, dpdaction=restart<br>
                  Security Associations (1 up, 0 connecting):<br>
                        tunnel[3]: ESTABLISHED 25 minutes ago,
                  192.168.10.40[192.168.10.40]...192.168.10.38[192.168.10.38]<br>
                        tunnel[3]: IKEv2 SPIs: c1a42433ade9fa28_i
                  a52cfea6d767c397_r*, pre-shared key reauthentication
                  in 24 minutes<br>
                        tunnel[3]: IKE proposal:
                  AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048<br>
                   <br>
                </p>
                <br>
                <div class="moz-signature"><br>
                  Thanks <br>
                  <br>
                </div>
                <div class="moz-cite-prefix">On Wednesday 07 February
                  2018 09:06 PM, Jafar Al-Gharaibeh wrote:<br>
                </div>
                <blockquote type="cite"
                  cite="mid:32aecd44-a585-6ce3-08d8-0c788516188c@atcorp.com">
                  <meta http-equiv="Content-Type" content="text/html;
                    charset=utf-8">
                  <br>
                  <br>
                  <div class="moz-cite-prefix">On 2/7/2018 9:22 AM,
                    Sujoy wrote:<br>
                  </div>
                  <blockquote type="cite"
                    cite="mid:ed47c3e7-77cb-eb89-8921-202ed5ddca9c@mindlogicx.com">
                    <meta http-equiv="Content-Type" content="text/html;
                      charset=utf-8">
                    <p>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"<br>
                    </p>
                  </blockquote>
                  "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? <br>
                  <br>
                  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. <br>
                  <br>
                  --Jafar<br>
                  <br>
                  <blockquote type="cite"
                    cite="mid:ed47c3e7-77cb-eb89-8921-202ed5ddca9c@mindlogicx.com">
                    <p> </p>
                    <p>    <br>
                    </p>
                    <p>   Config setup<br>
                    </p>
                    <p>        charondebug="all"<br>
                              uniqueids=yes<br>
                              strictcrlpolicy=yes<br>
                      conn %default<br>
                      conn tunnel #<br>
                              left=%any<br>
                              right=192.168.10.40<br>
                              ike=aes256-sha1-modp2048!<br>
                              esp=aes256-sha1-modp2048!<br>
                              keyingtries=1<br>
                              ikelifetime=1h<br>
                              lifetime=8h<br>
                              dpddelay=30<br>
                              #dpdtimeout=120<br>
                              dpdaction=restart<br>
                              authby=secret<br>
                              auto=route<br>
                              keyexchange=ikev2<br>
                              type=tunnel<br>
                      <br>
                    </p>
                    <p><br>
                    </p>
                    <p>root@client:~# ipsec up tunnel<br>
                      initiating IKE_SA tunnel[1] to 192.168.10.40<br>
                      generating IKE_SA_INIT request 0 [ SA KE No
                      N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]<br>
                      sending packet: from 192.168.10.38[500] to
                      192.168.10.40[500] (448 bytes)<br>
                      received packet: from 192.168.10.40[500] to
                      192.168.10.38[500] (456 bytes)<br>
                      parsed IKE_SA_INIT response 0 [ SA KE No
                      N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(MULT_AUTH)
                      ]<br>
                      remote host is behind NAT<br>
                      no IDi configured, fall back on IP address<br>
                      authentication of '192.168.10.38' (myself) with
                      pre-shared key<br>
                      establishing CHILD_SA tunnel<br>
                      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) ]<br>
                      sending packet: from 192.168.10.38[4500] to
                      192.168.10.40[4500] (348 bytes)<br>
                      received packet: from 192.168.10.40[4500] to
                      192.168.10.38[4500] (156 bytes)<br>
                      parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT)
                      N(MOBIKE_SUP) N(ADD_4_ADDR) N(TS_UNACCEPT) ]<br>
                      authentication of '192.168.10.40' with pre-shared
                      key successful<br>
                      IKE_SA tunnel[1] established between
                      192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]<br>
                      scheduling reauthentication in 2819s<br>
                      maximum IKE_SA lifetime 3359s<br>
                      <b>received TS_UNACCEPTABLE notify, no CHILD_SA
                        built</b><b><br>
                      </b><b>failed to establish CHILD_SA, keeping
                        IKE_SA</b><br>
                      received AUTH_LIFETIME of 2637s, scheduling
                      reauthentication in 2097s<br>
                      peer supports MOBIKE<br>
                      establishing connection 'tunnel' failed<br>
                    </p>
                    <p><br>
                    </p>
                    <p>root@client:~# ipsec statusall<br>
                      Status of IKE charon daemon <b>(strongSwan 5.3.3,
                        Linux 4.4.0-112-generic, x86_64)</b>:<br>
                        uptime: 2 minutes, since Feb 07 20:44:23 2018<br>
                        malloc: sbrk 2703360, mmap 0, used 519600, free
                      2183760<br>
                        worker threads: 7 of 16 idle, 5/0/4/0 working,
                      job queue: 0/0/0/0, scheduled: 4<br>
                        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<br>
                      Listening IP addresses:<br>
                        192.168.10.38<br>
                        192.168.3.107<br>
                       <br>
                      Connections:<br>
                            tunnel:  %any...192.168.10.40  IKEv2,
                      dpddelay=30s<br>
                            tunnel:   local:  uses pre-shared key
                      authentication<br>
                            tunnel:   remote: [192.168.10.40] uses
                      pre-shared key authentication<br>
                            tunnel:   child:  dynamic === dynamic
                      TUNNEL, dpdaction=restart<br>
                      Security Associations (1 up, 0 connecting):<br>
                            tunnel[1]: ESTABLISHED 2 minutes ago,
                      192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]<br>
                            tunnel[1]: IKEv2 SPIs: 175dcf9cdcf11b38_i*
                      9cc05896738a5e45_r, pre-shared key
                      reauthentication in 32 minutes<br>
                            tunnel[1]: IKE proposal:
                      AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048<br>
                      <br>
                    </p>
                    <div class="moz-signature">Thanks<br>
                      <br>
                    </div>
                    <div class="moz-cite-prefix">On Wednesday 07
                      February 2018 08:31 PM, Jafar Al-Gharaibeh wrote:<br>
                    </div>
                    <blockquote type="cite"
                      cite="mid:090b72a6-679e-4426-00d7-36b56ab71f2c@atcorp.com">
                      <meta http-equiv="Content-Type"
                        content="text/html; charset=utf-8">
                      Sujoy,<br>
                      <br>
                        Are you sure about <br>
                      <br>
                         rightsubnet=192.168.10.0/32<br>
                      <br>
                       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?<br>
                      <br>
                      --Jafar<br>
                      <br>
                      <br>
                      <br>
                      <div class="moz-cite-prefix">On 2/7/2018 12:44 AM,
                        Sujoy wrote:<br>
                      </div>
                      <blockquote type="cite"
                        cite="mid:2e766137-1a09-0455-12f6-1211cd7bfa85@mindlogicx.com">
                        <meta http-equiv="Content-Type"
                          content="text/html; charset=utf-8">
                        <p>Hi Noel,</p>
                        <p>Still cannot establish tunnel. logs doesn't
                          show anything. Can someone help to solve this.
                          <br>
                        </p>
                        <p>Client configuration</p>
                        <p>config setup<br>
                        </p>
                        <p>        charondebug="all"<br>
                                  uniqueids=yes<br>
                                  strictcrlpolicy=no<br>
                          conn %default<br>
                          conn tunnel #<br>
                                  left=%any<br>
                                  right=192.168.10.40<br>
                                  rightsubnet=192.168.10.0/32<br>
                                  ike=aes128-md5-modp1536<br>
                                  esp=aes128-sha1<br>
                                  keyingtries=%forever<br>
                                  ikelifetime=1h<br>
                                  lifetime=8h<br>
                                  dpddelay=30<br>
                                  #dpdtimeout=120<br>
                                  #dpdaction=restart<br>
                                  authby=secret<br>
                                  auto=start<br>
                                  keyexchange=ikev2<br>
                                  type=tunnel<br>
                                  mobike=no<br>
                                  #pfs=no<br>
                                  reauth=no<br>
                          <br>
                        </p>
                        <p>Server setup</p>
                        <p>config setup<br>
                        </p>
                        <p>        charondebug="all"<br>
                                  uniqueids=yes<br>
                                  strictcrlpolicy=no<br>
                          conn %default<br>
                          conn tunnel #conn %default<br>
                          conn tunnel #<br>
                                  left=%any<br>
                                  right=192.168.10.40<br>
                                  rightsubnet=192.168.10.0/32<br>
                                  ike=aes128-md5-modp1536<br>
                                  esp=aes128-sha1<br>
                                  keyingtries=%forever<br>
                                  ikelifetime=1h<br>
                                  lifetime=8h<br>
                                  dpddelay=30<br>
                                  #dpdtimeout=120<br>
                                  #dpdaction=restart<br>
                                  authby=secret<br>
                                  auto=start<br>
                                  keyexchange=ikev2<br>
                                  type=tunnel<br>
                                  mobike=no<br>
                                  #pfs=no<br>
                                  reauth=no<br>
                        </p>
                        <p><br>
                        </p>
                        <div class="moz-signature">root@client:~# <b>ipsec
                            up tunnel</b><br>
                          initiating IKE_SA tunnel[2] to 192.168.10.40<br>
                          generating IKE_SA_INIT request 0 [ SA KE No
                          N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]<br>
                          sending packet: from 192.168.10.38[500] to
                          192.168.10.40[500] (1064 bytes)<br>
                          received packet: from 192.168.10.40[500] to
                          192.168.10.38[500] (38 bytes)<br>
                          parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]<br>
                          peer didn't accept DH group MODP_2048, it
                          requested MODP_1536<br>
                          initiating IKE_SA tunnel[2] to 192.168.10.40<br>
                          generating IKE_SA_INIT request 0 [ SA KE No
                          N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]<br>
                          sending packet: from 192.168.10.38[500] to
                          192.168.10.40[500] (1000 bytes)<br>
                          received packet: from 192.168.10.40[500] to
                          192.168.10.38[500] (392 bytes)<br>
                          parsed IKE_SA_INIT response 0 [ SA KE No
                          N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG)
                          N(MULT_AUTH) ]<br>
                          remote host is behind NAT<br>
                          no IDi configured, fall back on IP address<br>
                          authentication of '192.168.10.38' (myself)
                          with pre-shared key<br>
                          establishing CHILD_SA tunnel<br>
                          generating IKE_AUTH request 1 [ IDi
                          N(INIT_CONTACT) IDr AUTH SA TSi TSr
                          N(MULT_AUTH) N(EAP_ONLY) ]<br>
                          sending packet: from 192.168.10.38[4500] to
                          192.168.10.40[4500] (332 bytes)<br>
                          received packet: from 192.168.10.40[4500] to
                          192.168.10.38[4500] (108 bytes)<br>
                          parsed IKE_AUTH response 1 [ IDr AUTH
                          N(TS_UNACCEPT) ]<br>
                          authentication of '192.168.10.40' with
                          pre-shared key successful<br>
                          IKE_SA tunnel[2] established between
                          192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]<br>
                          scheduling rekeying in 2525s<br>
                          maximum IKE_SA lifetime 3065s<br>
                          <b>received TS_UNACCEPTABLE notify, no
                            CHILD_SA built</b><b><br>
                          </b><b>failed to establish CHILD_SA, keeping
                            IKE_SA</b><b><br>
                          </b><b>establishing connection 'tunnel' failed</b><br>
                          root@client:~# <br>
                          <br>
                          <br>
                          Ipsec statusall<br>
                          <br>
                          Status of IKE charon daemon (<b>strongSwan
                            5.3.3, Linux 4.4.0-112-generic, x86_64</b>):<br>
                            uptime: 41 seconds, since Feb 07 12:08:32
                          2018<br>
                            malloc: sbrk 2703360, mmap 0, used 519216,
                          free 2184144<br>
                            worker threads: 7 of 16 idle, 5/0/4/0
                          working, job queue: 0/0/0/0, scheduled: 2<br>
                            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<br>
                          Listening IP addresses:<br>
                            192.168.10.38<br>
                            192.168.3.107<br>
                          <br>
                          Connections:<br>
                                tunnel:  %any...192.168.10.40  IKEv2<br>
                                tunnel:   local:  uses pre-shared key
                          authentication<br>
                                tunnel:   remote: [192.168.10.40] uses
                          pre-shared key authentication<br>
                                tunnel:   child:  dynamic ===
                          192.168.10.0/32 TUNNEL<br>
                          Security Associations (1 up, 0 connecting):<br>
                                tunnel[1]: ESTABLISHED 41 seconds ago,
                          192.168.10.38[192.168.10.38]...192.168.10.40[192.168.10.40]<br>
                                tunnel[1]: IKEv2 SPIs:
                          53b251675b863a7d_i* 57d33cd8149f729f_r,
                          rekeying in 41 minutes<br>
                                tunnel[1]: IKE proposal:
                          AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536<br>
                          <br>
                          <br>
                        </div>
                        <div class="moz-cite-prefix">On Tuesday 16
                          January 2018 11:23 PM, Noel Kuntze wrote:<br>
                        </div>
                        <blockquote type="cite"
                          cite="mid:47eaf00a-0170-2c97-19c8-68cb10b2891f@thermi.consulting">
                          <pre wrap="">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:
</pre>
                          <blockquote type="cite">
                            <pre wrap="">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:
</pre>
                            <blockquote type="cite">
                              <pre wrap="">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] <a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples" moz-do-not-send="true">https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples</a>

On 28.12.2017 08:51, Sujoy wrote:
</pre>
                              <blockquote type="cite">
                                <pre wrap="">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.
</pre>
                              </blockquote>
                            </blockquote>
                          </blockquote>
                        </blockquote>
                        <br>
                      </blockquote>
                      <br>
                    </blockquote>
                    <br>
                  </blockquote>
                  <br>
                </blockquote>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>