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



  • 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)



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



  • 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,



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



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



  • 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



  • 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>



  • Any help please?



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