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

AlexP
Meraki Employee

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

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:

 

Screen Shot 2021-07-20 at 3.49.22 PM.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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:

 

Screen Shot 2021-07-20 at 3.55.35 PM.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

3 REPLIES 3
PhilipDAth
Kind of a big deal

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

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
Meraki Employee

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


@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
Meraki Employee

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

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

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.