Solved
I got a problem here I'd love for one of you to swoop in and solve for me 🙂
I have a customer where we're replacing the Sonicwall that's currently installed at their "HQ" site with a Meraki MX. For now at least they want to keep the Sonicwall at the remote branches they have. They've been doing a Hub and Spoke VPN topology with the Sonicwalls with the full tunneling of traffic back to the HQ site. No DIA at the branches.
So, the problem is that with the MX in NAT mode at the HQ, I can't figure out how to set up the full tunneling of traffic from the branch. If the MX was in concentrator mode then I think this would be doable as the 0.0.0.0/0 route would appear in the VPN page and I could just make it "Yes" to In VPN. But with NAT mode there now way that I see to specify the encryption domain on the Meraki side to "everything".
Quick and dirty diagram to illustrate:
Alright, I have a really ugly solution to this problem that satisfies the requirements... Or at least I think I do. My initial testing seems to point towards it working the way it's supposed to, but be warned that this is likely well into unsupported territory so if anyone reads this and wants to use it know you're probably on your own. This method will also cause the Dashboard to throw a warning about more specific routes every single time you go to commit a change. It can safely be ignored, but it will do it Every. Single. Time. 😞
First, set up a default route on the hub MX, with a next hop that doesn't exist, and set it to be active when the host responds to ping. By doing this the route will never be active, but it will add a 0.0.0.0/0 option in the Site-to-site VPN page that you can include in the VPN.
You should have something like the following:
Here's the VPN page with the never-active quad zero as an option:
Now that we have the correct option present we can configure the other end of the tunnel to match the 0.0.0.0/0 encryption domain, and voila! Full tunnel from non-Meraki spoke to Meraki Hub.
Yup. That has crossed my mind. Turn the Sonicwall into a concentrator fo sorts... The downside there is this customer was sold the Meraki as a Sonicwall replacement, so to now turn around and tell them that they have to keep them isn't the most desirable solution.
Alright, I have a really ugly solution to this problem that satisfies the requirements... Or at least I think I do. My initial testing seems to point towards it working the way it's supposed to, but be warned that this is likely well into unsupported territory so if anyone reads this and wants to use it know you're probably on your own. This method will also cause the Dashboard to throw a warning about more specific routes every single time you go to commit a change. It can safely be ignored, but it will do it Every. Single. Time. 😞
First, set up a default route on the hub MX, with a next hop that doesn't exist, and set it to be active when the host responds to ping. By doing this the route will never be active, but it will add a 0.0.0.0/0 option in the Site-to-site VPN page that you can include in the VPN.
You should have something like the following:
Here's the VPN page with the never-active quad zero as an option:
Now that we have the correct option present we can configure the other end of the tunnel to match the 0.0.0.0/0 encryption domain, and voila! Full tunnel from non-Meraki spoke to Meraki Hub.
