Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSec Tunnel IKE2 to ASA does only the last SA; not all 4

    Scheduled Pinned Locked Moved IPsec
    9 Posts 2 Posters 3.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      alfredo
      last edited by

      Dear Forum,

      Trying to setup an IPSec Tunnel IKE2 to a big datacenter using ASA. Everything seems to work but charon can only do one SA /Phase II at a time. We need all 4 to work. Please see attached screenshot: with all 4 activated, only the last SA gets connected; and when deactivating the last 3, then the first works.

      Am I doing something wrong, or am I missing something, or is this a bug?

      Thanks for any help,

      Alfredo,
      ![Screen Shot 2015-07-01 at 19.05.57.png](/public/imported_attachments/1/Screen Shot 2015-07-01 at 19.05.57.png)
      ![Screen Shot 2015-07-01 at 19.05.57.png_thumb](/public/imported_attachments/1/Screen Shot 2015-07-01 at 19.05.57.png_thumb)

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        It's a Cisco bug/lacking feature.
        https://redmine.pfsense.org/issues/4704

        1 Reply Last reply Reply Quote 0
        • A
          alfredo
          last edited by

          Hallo Chris,

          Thanks  but I don't quite understand that dialog. What should I do from the pfSense side - in plain english? We cannot really do anything about that ASA on the other end. And I really wanna keep pfSense for this end.

          Thanks so much,

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            Switching it to IKEv1 is the only option today. Cisco doesn't support multiple traffic selectors in a single child SA with IKEv2, which is the standard means of doing that. Cisco needs to fix that in the ASA, pretty much everything else does it the same way we do.

            There is a way we can hack the config to make it work with an ASA as a non-default option, just not something we've implemented. If Cisco doesn't fix that soon, we'll end up adding that option for 2.3 release, but that'll be a couple months from now.

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              Another option might be to CIDR summarize the subnets in question. If your end's 10.0.238.0/24 and 10.0.239.0/24, that's the same as 10.0.238.0/23. Other end could be similar. Then you could have one P2 to accomplish same.

              1 Reply Last reply Reply Quote 0
              • A
                alfredo
                last edited by

                Thanks; you're awesome. We love pfSense. Keep up the good work and we're looking forward to 2.3! We hope that pfSense will soon be bigger - in terms of deployments - than Cisco anyhow  ;D

                1 Reply Last reply Reply Quote 0
                • A
                  alfredo
                  last edited by

                  Hallo Chris,

                  Three more questions:

                  [1] That tunnel shown on the screenshot works only when manually starting it up from pfSense. Starting it up by traffic fails with:
                  parsed CREATE_CHILD_SA response 16 [ N(NO_PROP) ]
                  Jul 2 15:16:40 charon: 10[IKE] <con1|3>received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
                  Jul 2 15:16:40 charon: 10[IKE] <con1|3>received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
                  Jul 2 15:16:40 charon: 10[IKE] <con1|3>failed to establish CHILD_SA, keeping IKE_SA

                  I would assume this is because of the same problem.

                  [2] Would you be able to provide us with your patch so we don't have to wait for 2.3?

                  [3] Yes, the remote network, we can CIDR summarise to 10.0.238/23;

                  but can we really CIDR summarise our side: we have our subnet 10.1.10.0/24 NATting to the providers' private  10.41.38.0/24, and subnet 10.1.20.0/24 NATting to the providers' private  10.41.39.0/24. So we have 10 point difference and the provider a 1 point different in the third octet. I don't think NAT would work unless the provider gives us 10.41.48.0/24, or we take 10.1.11.0/24? Is that right? Or do you have a special NAT trick so that it could still work?

                  Thanks so much.

                  Alfredo</con1|3></con1|3></con1|3>

                  1 Reply Last reply Reply Quote 0
                  • A
                    alfredo
                    last edited by

                    Any help please?

                    1 Reply Last reply Reply Quote 0
                    • A
                      alfredo
                      last edited by

                      Still waiting for help; yes, it works fine under IKEv1; but need to have it working in IKEv2.  ;) Either with hack, or NATting 4 (was 2 before) local subnets 10.1.10.10/24,10.1.10.20/24,10.1.10.110.110/24, and 10.1.10.120 into 10.41.38.0/22, so we can only use 1 SA. Tried NAT 1:1 but that did not work.

                      Any help appreciated.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.