I’d like to preface this by saying I have only been in my Networking career for about 3 months and still working towards my CCNA so please forgive my ignorance here and I’ll take on all criticism to improve my knowledge and understanding.
I have been tasked by my company to roll out new Meraki hardware to 50+ sites. Each site is behind an MPLS circuit that connects directly to our Core Network, before breaking out to the internet.
Previously, the hardware setup for these sites was IPVPN Router (10.X.X.6) > Venue Switch (10.X.X.1), however with the addition of the Meraki hardware, this setup has changed to IPVPN Router (10.X.X.6) > Meraki MX (10.X.X.1) > Meraki Switch (Addressed on new Managment VLAN for the network).
This setup works for the most part, all devices are connected to the internet, I can ping our core network servers from the site, but I cannot ping anything past the MX Appliance from our core network. The issue this is causing is CCTV access from HQ - any site that I have already changed to Meraki falls off the CCTV management software.
To resolve this, I believe I have to enable No-NAT for the network, then create the appropriate Firewall rules to allow inbound traffic from our core network. I did this, but it didn’t work and I’m not sure what I’m doing wrong.
I’m confused - what purpose is the MX performing here (short and long term)? Normally companies buy SD-WAN products like MX’s to replace MPLS but that requires you to buy internet circuits in the locations first. Your Meraki rep should be well versed in the migration path to get you off MPLS, unless that’s not your goal?
For example - if you’re not planning on using SD-WAN on the MX’s you need to shut off the Site to Site VPNs if you didn’t already.
You are natted behind the WAN IP of the MX. In order to do so, you can also create S2S VPN tunnels through the MPLS to a concentrator that needs to reside in the DC where internet is also breaking out. Then your networks behind the mx’s become part of the whole network…
Think thats the easiest way to do so…
No-nat and fw rules inbound/outbound makes it far to complex…
Your end goal is to retire MPLS and go full SD-WAN?
I went through this. The MX doesn’t like MPLS as a WAN interface. So we had to work around that.
Previously we had a Cisco 4321 router handling MPLS with BGP facing the MPLS, and OSPF on the LAN side. So when the MPLS went down, BGP routes would disappear. The default route would then be to the Palo that had a tunnel back to the DC. We replaced the Palo with an MX as phase 1.
Phase 2 was taking down MPLS circuits. I don’t recal the exact process I did remotely to retire the 4321 from all routing duties and put the MX to take over. But it was something like shutting he port on the switch that connected to it, then re-configuring the MX with VLANs the old Cisco had. (Most sites were router on stick since they all had less than 20 users)
Phase 3: Full LAN upgrade
Eventually I’d visit the site again and upgrade our ancient 3750s or 10/100 old 2960 switches with Meraki MS-125s and drop in a second MX with a Nighthawk LTE hotspot for the backup link.
We had some sites that are much larger and either have diverse Fiber (one from ATT, another from Spectrum for example, making sure the Spectrum fiber enters the building from a separate direction than the ATT, although I still don’t trust that and have an “oh s**t” cable line I can plug in just in case).
After everything I’m not exactly a fan of Meraki switches since I come from a long Cisco background and like my CLI. But it does make it easier to cross train the systems people to handle things when I’m unavailable. And having everything in a single pain of glass is nice.
Note, prior to phase 2 you need to make sure you have routes from an MX only site to the MPLS sites. Usually your DC is where you’ll put this.
Also, the reason you have to go through all these gymnastics is because the MX doesn’t exactly do BGP. And in fact it can’t even listen for OSPF on its LAN even though it can advertise with OSPF. If you need to continue running dynamic routing protocols you need to plan to have non-MX routers in place to handle this.
Buy ubiquiti routers to handle the MPLS. When I last tried to do this the Meraki security appliances did not seem like the right fit to handle MPLS. I’m not saying it can’t work but it might be messy. If it’s short term, it’s even better.
Your diagram as a reference point If you’re operating the MX in default mode with MPLS routing and a single WAN circuit, establishing a transit VLAN between the MX and MPLS router allows for moving L3 and DHCP to the MX. Ensure a default route to the MPLS router from the MX, and employ a summary route on the MPLS router pointing back to the MX for optimal routing.
MPLS should be plugged into your switch and not the Firewall. Merkai MX is capable of doing a no NAT. Create static routes to get to MPLS network on the switch and an all 0.0.0.0 route for everything else pointing to your firewall and out to the internet.
Short-term the MX is being used for DHCP, until we are out of contract for the MPLS circuits and can change them over. Long-term the MX will be used for SD-WAN with the Site-to-Site VPN instead of the MPLS circuit.
Site-to-Site VPN is currently off on all locations that have the MPLS circuit in place.
Yes. But you need to set the default route in the tunnel as well…
So when you select the hubs, check the box behind for the default route in tunnel.
Else only traffic to known subnets at or behind the concentrator is send trought the tunnel. "Internet"traffic is routed through your MPLS underlay to the internet.
So enable s2s vpn, all subnets in the tunnel and check default route.
You probably want to configure a pass through concentrator with OSPF or BGP in the Central DC for route exchange between vpn sites and all DC/non VPN sites…