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.

2 REPLIES 2
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.

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.