MX Support - trying to crowdsource solutions for IKEv2 Non-Meraki VPN

[AlexP]

Hello everyone,

TL;DR - if you know how to fix IKEv2 traffic selector problems, please help us compile them here so we can start a list!

Part of the trends we've been noticing lately with non-Meraki VPN is that a lot of vendors are getting tripped up on this requirement: https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#NOTE_For_IKEv2

To understand why this is a problem, it helps to take a quick look at part of an IKEv1 packet:

The two sets of ID values in that packet represent the subnets with which we want to build the tunnel (in this case, 172.16.1.0/24 and  192.168.128.0/24 respectively). 

In IKEv1, the requirement is that only a single pair of subnets constitutes a tunnel, but while no such restriction exists in IKEv2, many vendors have still chosen to implement things with that restriction in place.

To visualize, here's how Meraki tries to build an IKEv2 tunnel using the equivalent of the above packet:

You can see that there are now multiple ranges in there, not just a single pair (ignore the fact that those /32's fall within the /24's in question for now)

I've been seeing many cases where vendors don't seem to like this without either changing settings, or otherwise messing around with subnet ranges to compensate for the fact that they're only willing to use one of those proposed values.

As a result, I've been doing research, and I've been failing to come up with a lot of documentation we can help others reference when trying to set things right. So far, Barracuda is the only vendor with whom I've found an explicit setting to avoid: https://campus.barracuda.com/product/cloudgenfirewall/doc/53248930/how-to-configure-a-site-to-site-i... (for the curious, "One VPN Tunnel per Subnet Pair" needs to be disabled)

If anyone can help us start compiling documentation on how to make things right here, it'd be greatly appreciated.

[PhilipDAth]

In Cisco Enterprise space, like on an ASA, you can configure it to request all the subnets at once in the encryption domain in a single SA, or to request them using multiple SAs.

You use a single access-list entry to request them all at once (using object groups).

You use multiple access-list entries to request them one at a time.

When you get it to use multiple SAs to a Meraki, Meraki sees the attempts to add additional SAs as a request to REPLACE the original SA, rather than add.  So that approach doesn't work.

When configuring ASA's, I find if one approach doesn't work to another vendor that the other usually does.

Also note that many IKEv2 implementations want to use routed mode and will try and request 0.0.0.0/0 to 0.0.0.0/0 as the encryption domain and then the remote end has to propose to narrow it down.

Or you could accept, and then simply route the traffic over the VPN knowing that the encryption domain includes everything (basically becomes a VTI).

If using Linux as your base (which I'm guessing you are), I quite like using VTIs and IKEv2 routed mode.  You use the xfrm engine in the kernel to "mark" the packets internally to enable automatic routing into the correct VTI.

If your Linux kernel is using the modern netplan, it would look something like:

network: 

    version: 2 

    tunnels: 

        vti3: 

            mode: vti 

            local: a.b.c.d

            remote: q.w.e.r

            key: 3 

            addresses: 

                - 169.254.105.193/30 

            routes: 

                - to: 10.0.0.0/24 

                  via: 169.254.105.194 

...

The "key" says to mark the packets internally with a key of 3 (needs to be unique for every VTI).

[AlexP]

---

@PhilipDAth wrote:

In Cisco Enterprise space, like on an ASA, you can configure it to request all the subnets at once in the encryption domain in a single SA, or to request them using multiple SAs.

You use a single access-list entry to request them all at once (using object groups).

You use multiple access-list entries to request them one at a time.

When you get it to use multiple SAs to a Meraki, Meraki sees the attempts to add additional SAs as a request to REPLACE the original SA, rather than add.  So that approach doesn't work.

---

This is correct, and at the root of the problem; the daemon we use bundles all the traffic selectors under a single child SA, so if a peer does selector narrowing, we'll build a policy with just those narrowed selectors, and reject any further attempts to build additional SAs because they match to what is technically an existing one.

I appreciate the tip about access lists though, and will do some following up on that end of things.

[AlexP]

I've been labbing this, and I can't seem to get it to behave differently - perhaps you can point out what I'm doing wrong here.

Here's my object group:

MX-to-ASA-ikev2-testing# sho object-group id IKEv2
object-group network IKEv2
description: Local Subnets for IKEv2 VPN
network-object 10.99.99.0 255.255.255.0
network-object 10.100.100.0 255.255.255.0

From there, I bound it to an extended ACL 

MX-to-ASA-ikev2-testing# sho run | b access-list
access-list 90 extended permit ip 172.24.6.0 255.255.255.0 172.24.0.0 255.255.255.0
access-list 110 remark - this should allow for multiple traffic selectors in IKEv2
access-list 110 extended permit ip object-group IKEv2 192.168.0.0 255.255.255.0 # 192.168.0.0/24 is the remote on the MX

And then finally the crypto map:

MX-to-ASA-ikev2-testing# sho run | b crypto
crypto ipsec ikev2 ipsec-proposal SECURE
protocol esp encryption aes-256 aes-192 3des
protocol esp integrity sha-1 md5
crypto ipsec security-association pmtu-aging infinite
crypto map MXMap 20 match address 110
crypto map MXMap 20 set peer 172.24.0.13
crypto map MXMap 20 set ikev2 ipsec-proposal SECURE
crypto map MXMap 20 set security-association lifetime seconds 28800
crypto map MXMap 20 set security-association lifetime kilobytes unlimited
crypto map MXMap interface outside
crypto ca trustpool policy
crypto ikev2 policy 1
encryption 3des
integrity sha
group 2
prf sha
lifetime seconds 28800
crypto ikev2 enable outside

The tunnel is coming up between them, but with the ASA as the responder, it's still only using one of the two proposed traffic selectors:

MX-to-ASA-ikev2-testing# sho crypto ikev2 sa

IKEv2 SAs:

Session-id:3, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local Remote Status Role
20632227 172.24.6.129/4500 172.24.0.13/4500 READY RESPONDER
Encr: 3DES, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/818 sec
Child sa: local selector 10.99.99.0/0 - 10.99.99.255/65535
remote selector 192.168.0.0/0 - 192.168.0.255/65535
ESP spi in/out: 0x828dcbf7/0xc1d5d2dc

This, in spite of the fact that debugging shows it received selectors for both of its local subnets (don't mind the fact that NTP isn't working):

Jan 02 2003 19:38:32: %ASA-7-711001: (4): Num of TSs: 2, reserved 0x0, reserved 0x0
Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 1, length: 16
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 2048, end port: 2048
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 192.168.0.1, end addr: 192.168.0.1
Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 0, end port: 65535
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 192.168.0.0, end addr: 192.168.0.255
Jan 02 2003 19:38:32: %ASA-7-711001: (4): TSrJan 02 2003 19:38:32: %ASA-7-711001: (4): Next payload: NOTIFY, reserved: 0x0, length: 56
Jan 02 2003 19:38:32: %ASA-7-711001: (4): Num of TSs: 3, reserved 0x0, reserved 0x0
Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 1, length: 16
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 2048, end port: 2048
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 10.99.99.2, end addr: 10.99.99.2
Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 0, end port: 65535
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 10.99.99.0, end addr: 10.99.99.255
Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 0, end port: 65535
Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 10.100.100.0, end addr: 10.100.100.255

[PhilipDAth]

Use this access list instead:

access-list 110 permit IP 10.99.99.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list 110 permit IP 10.100.100.0 255.255.255.0 192.168.0.0 255.255.255.0

Does that give you a different result with the negotiation?  I'm expecting it will.

[AlexP]

No net difference from what I can tell 😞

MX-to-ASA-ikev2-testing(config)# sho access-list 110
access-list 110; 2 elements; name hash: 0xe9cd5715
access-list 110 line 1 remark - this should allow for multiple traffic selectors in IKEv2
access-list 110 line 2 extended permit ip 10.99.99.0 255.255.255.0 192.168.0.0 255.255.255.0 (hitcnt=0) 0x6693a7e5
access-list 110 line 3 extended permit ip 10.100.100.0 255.255.255.0 192.168.0.0 255.255.255.0 (hitcnt=0) 0x4c2f28d1

The net result is the same in the debugging as well

[PhilipDAth]

Sorry to let you down - that has not been my experience (with it producing the same result).

Several times when I have not been able to get an ASA to build a VPN to a third-party device that involved multiple sets of subnets flipping from an object group to an access list has resolved it.  Either that or the ASA is acting differently based on the vendor ID received.

[PhilipDAth]

Or rather the VPN builds but not for all the subnets, and flipping from object groups to access-lists makes it work for all subnets.

[PhilipDAth]

I just did an interesting IKEv2 VPN from StrongSwan on Ubuntu to an old Cisco ASA 5510.

Normally when there are multiple subnets you can just comma separate them.  However when I tried this approach, only one of the two would come up.  When one started working the other stopped.

rightsubnet=192.168.1.0/24,192.168.2.0/24

I found this article talking about the problem:

https://wiki.strongswan.org/issues/2529 

it said that the ASA's can only negotiate more than one traffic selector (subnet) per CHILD_SA for IKEv2.

The fix was to list the additional subnets as additional connections hanging off the primary.

conn test-vpn1
 <other lines of config>
 rightsubnet=192.168.1.0/24
 ...
conn test-vpn2
 also=test-vpn1
 rightsubnet=192.168.2.0/24

I watched it build the VPN when it did this.  It brings up the SAs one at a time for each subnet.  You can see it adding them.

[PhilipDAth · Accepted solution]

Another article I found talking about it.

https://serverfault.com/questions/904028/strongswan-to-cisco-asa-with-multiple-right-subnet 

[AlexP]

Yeah, this was the very problem I was hoping to resolve. It's rather disappointing that Cisco still hasn't fixed it in 3+ years considering how easier a single SA for everything makes it to troubleshoot (not to mention how much better it scales), but if nobody else knows of ways to get that to work, and if nobody else is going to chime in with other vendors that seemingly also fail to do multiple TS's per SA, I think I need to take some feedback about this with regards for IKEv2 and see if we can make the argument that it needs re-implementing.