MX65 as firewall for VeloCloud SD-WAN - Routing issue

DunJer622
Building a reputation

MX65 as firewall for VeloCloud SD-WAN - Routing issue

Greetings,

 

I've been using MX65 units for several VPN endpoint and they have been working well.  However, for some of our larger offices, a decision was made to implement VeloCloud SD-WAN, with the MX65 units serving as the firewall.  I spent a lot of time working with Sprint (reselling VeloCloud solution) on the design and everything was given the green light.  However, upon implementing the first remote location, I have ran into a significant problem.  I can't simply add the static route to send all traffic over the VeloCloud netowork, as it says that the next hop is invalid.  I have the WAN IP on the same subnet as the VeloCloud LAN and the VeloCloud network sees the MX65 without issue.  However, I can't route traffic through it.  I have done a lot of searches, but they seem to all talk about using the MX65 as the SD-WAN device.  That doesn't help.  I feel like I'm overlooking a simple configuration setting, so I'm hoping someone in the community has performed something similar and has an answer for me.

 

Right now, the SD-WAN device has a LAN IP of 172.30.19.1, while the Meraki WAN IP is 172.30.19.2.  The Meraki gets to the Internet fine, but it doesn't see my HQ networks 192.168.1.0/24.  What am I missing?

 

Thanks for any assistance that you can provide.

 

Jeremy

16 Replies 16
PhilipDAth
Kind of a big deal
Kind of a big deal

That should work fine. Can you please provide a screenshot when it is rejecting the static route being added.  It is likely to be a small typo.

DunJer622
Building a reputation

image.png

leads to:

 

image.png

I do understand there being an error, as 172.30.19.1 is only known to the Meraki MX as the WAN1 gateway (as WAN1 IP is 172.30.19.2).  However, this is where I'm stumped, as I don't know how to tell the Meraki to use the WAN1 port for basically everything, as the VeloCloud SD-WAN has theoretically been configured with all our private networks (192.168.1.0/24, 192.168.202.0/24, etc.).  I'm starting to think that I may need a VPN, but that would defeat any of the routing programmed into the VeloCloud (and I'd be relying on dynamic DNS to establish the tunnel as the WAN IPs for the Meraki units on both sides would be private, as the VeloCloud units are connected to the ISPs).  I've also been looking at this as possibly treating this as being connected to an MPLS (which we are technically replacing).

DunJer622
Building a reputation

PhilipDAth
Kind of a big deal
Kind of a big deal

You can't add routes via a WAN port.  You would need to add a VLAN on the MX and route via that - but you would still need to plug something in a WAN port to give the MX Internet access so it can talk to the cloud.

 

I think you could be best to put the MX into passthrough mode, and let the Velocloud box do all the routing.

https://documentation.meraki.com/MX/Networks_and_Routing/Passthrough_Mode_on_the_MX_Security_Applian...

DunJer622
Building a reputation

"You can't add routes via a WAN port.  You would need to add a VLAN on the MX and route via that - but you would still need to plug something in a WAN port to give the MX Internet access so it can talk to the cloud."

 

The problem with this is the fact that this config would require me to have the SD-WAN (VeloCloud) router LAN connected to the Meraki LAN.  The VeloCloud (520) is the WAN, as it has all 3 ISP circuits connected to it.  I did testing with this design, with mixed results, but without anything in the WAN, it severs cloud management of the Meraki unit.  As I do have public static IPs, I could have a second ISP connection to the WAN1 port on the Meraki, but I'd be concerned with firewall effectiveness, as allowing the default ANY/ANY for LAN to LAN traffic would be a risk.

 

I'm going to test Passthrough mode with a test unit, to confirm functionality and access, but it won't be an exact test.

 

I'm just hoping that someone will see this conversation and say, "Hey, I did this exact thing with a Meraki firewall and here's how!"  I'm also wondering if the use of /24 subnets versus /30 is coming into play.

PhilipDAth
Kind of a big deal
Kind of a big deal

If the VeloCloud solution is connected to a dedicated WAN port you could create a traffic shaping rule to send traffic out that specific port.  Note that the internal LAN traffic will be NATed to the IP address on the WAN port .

Screenshot from 2018-09-11 09-18-02.png

DunJer622
Building a reputation

I actually tried this setup on Friday, while troubleshooting (although I had the destination be 192.168.1.0/24), but it had no effect.  I just assumed that this didn't work as this is simply stating which circuit to use, but not actually providing a next hop for a route.

JasonCampbell
Getting noticed

I'm not quite sure what the issue is here. The Velocloud device is your SDWAN appliance now, hook it up to WAN1. No other WAN connections go to Meraki; they go to Velocloud appliance now. If you can't AutoVPN then you need to add the subnet locally to the MX. Give it an IP in the subnet and if Velocloud is working correctly you should have access to the subnet at that point.
DunJer622
Building a reputation

I'm not sure that I'm following you, Jason.  I don't want to create a VPN with the Meraki, as that encrypts the traffic and defeats the purpose of the VeloCloud traffic management.  I do have a VPN created as a workaround, currently, but it certainly isn't preferred.  My understanding is that I simply need to have the Meraki point traffic at the VeloCloud LAN and the VeloCloud network will take it from there.  However, that is the problem, as I can't establish the static route.

PhilipDAth
Kind of a big deal
Kind of a big deal

Have the VeloCloud devices be the default gateway for your network, and use the MX in transparent mode.

DunJer622
Building a reputation

Yeah, that is one way to make it work, but it puts all the VLAN and DHCP management onto the VeloCloud 520, creating undesired overhead and a definite departure from our current MX setup.  We'd have to really rely on switches to isolate all the traffic for the different VLANs (especially since we don't let any of our Wi-Fi networks interact with wired production VLANs).  I was hoping to just have this be a routing issue that could be resolved, allowing us to have basically everything but the circuits be managed by the Meraki device(s).

 

Thanks,

 

Jeremy 

Elementalism
Conversationalist

I am curious OP, did you ever find a solution? We are about to deploy Velocloud via AT&T and realized there arent many real security features built in.  So I am kind of scrambling to figure out how to implement something that can do traditional firewall duties such as L3-4 and UTM functionality.  I was thinking maybe we could put an MX behind the Velocloud and let filter traffic between subnets. 

 

The pass-through option presented in this thread might work. Anybody tried it?

PhilipDAth
Kind of a big deal
Kind of a big deal

I have used pass through mode on a general WAN and it worked great.

DunJer622
Building a reputation

I tested it, and it worked, but it would be an administrative nightmare, as I have several VLANs and moving the management to the VCE would really suck (even with Orchestrator).  Creating a VPN with the MX has generally worked fine and then you have full control of the endpoint networks through the Meraki.  My understanding is that a beta version of the MX firmware addresses the "No NAT" issue, but I haven't seen it, yet.  I'll be doing more testing in Q2 2019.

fuzzy_poodle
Comes here often

Hi there ... i am facing similar issue as I need to build a mix of sites with Meraki Auto VPN and some sites on Non-Meraki SD-WAN ... how did you solve the interworking ? Back to back MX to SD-WAN appliance ?   TIA

DunJer622
Building a reputation

Yes.  I have all my Meraki endpoints (MX65) creating a VPN back to an MX64 hub at my DC.  Not ideal, as it masks the traffic across the VeloCloud network, but it is working.

 

Jeremy

Get notified when there are additional replies to this discussion.