We just tested it on a lab that we created for this purpose (2 MX's and 2 routers to simulate the MPLS) but the plan is to move to production this week.   What is important to have clear is : 1.- The MPLS has to be on the LAN of the MX. 2.- To have an SDWAN  tunnel up (not ordinary VPN's) using a WAN port.  3.- To understand the purpose of each route of your table, the priority of each route and to be clear what happens when one of your routes overlap another one (the redundant one). If you are not clear about the purpose of each of your routes and how they behave in every scenario, then it could not work as it should. ... View more

Hi Arun, I think Brandon's probably got the best way forward for you on this Create a VLAN that matches the /29 public range you have Build 1:1 NAT rules that match public IPs to private VLAN IP address (one for each in the subnet that's useable) The Meraki MX will operate as a NAT device unless you enable NO-NAT beta feature, the above rules will allow inbound traffic to pass the MX Firewall without solicitation.  The ONLY other way to do this with a Meraki would be to combine NO-NAT beta version with the Meraki MX being moved to a Stateless version (through support ticket), to then you'd be responsible for defining all inbound FW rules and allow traffic to pass through without being blocked by the MX. Be careful if you're using devices behind the MX to build VPNs as well, additional rules would need to be applied to allow ESP through. ... View more

Same issue here. Got on at 17:50. Kept refreshing constantly, no log messages after 17:44. Finally at 18:01 2 1/2 pages of new entries showed up. Do they only update every 15 minutes? Makes troubleshooting VPNs and such quite difficult. ... View more

Just out of curiosity, does the Sky device sit in front (as in the MX Wan connects to the Sky device) or behind the Meraki device (LAN)? ... View more

Just tested and blocking port 80 and 443 to the IP of the MX HUB has indeed worked, under the site-to-site VPN firewall rules. I can ping it, everything still works from the spoke, I just can't access the MX local status page anymore.  Hurray !   Just wish the setting under General would have worked like it was supposed to, so I didn't have to figure this out lol.  ... View more

@Q313 if you have internal services that you want to publish externally you can use 1:1 NAT to map the internal servers to a unique external address.  You just cannot do this for VPN connections or subnets. ... View more

Yes, enabling load balancing will push both connections into an Active-Active state. Try to ensure you set your uplink speeds correctly as the load balancing feature will use the delta between WAN 1 and WAN 2s settings as a ratio for traffic management. Example WAN 1 is 100Mbs WAN 2 is 50Mbs That's a 2:1 ratio and thus 2/3rds of traffic will be pushed normally down WAN 1 and WAN 2 will take the remainder (unless there are other instructions to put specific types of traffic down one connection, or there's an outage.) Meraki wont split session traffic over 2 uplinks as well, so a voice call or download/upload will only use one connection at any one time, and not an aggregate of both. E.G. it doesn't make your speed 150Mbs but gives you that in throughput. ... View more

Hey Everyone,   Just wanted to confirm what Gary has posted as the solution on this thread.   If anyone has any lingering issues, please check in with your ISPs and/or reach out to Meraki Support.   If anyone has any specific questions for myself please don't hesitate to send me a DM.     Rodrigo Meraki Support  ... View more

It seems like spare MX is also responding to Azure requests and creating a tunnel which it should not, and this is messing with route table. only one tunnel should be connected for this to work. ... View more

@WillN  I had that same thought because of the short amount of time it was online.  I use templates to push out my configurations and my template uses version MX14.45 which is stable release.  I did not look to see what version is shipped so I'll have to wait for my replacement (RMA was initiated yesterday).  I am wondering if I should upgrade my code on the template to 14.50 but found these not so satisfying entries in the code notes.    Although 14.50 did say it fixed this:   Resolved an issue that could result in MX67(W) and MX68(W,CW) appliances entering a reboot loop if 802.1X port authentication was configured while wireless was also enabled.   The caveats still show this: "We have recently become aware of an issue introduced in this firmware version that may result in communication issues between devices connected to ports 3-7 and devices connected to ports 8-12 on MX68(W,CW) appliances. We are working to provide an updated firmware version that resolves this issue as quickly as possible. Until that version is available, we will not be scheduling any further upgrades to MX 14.50 and we advise customers take additional caution before upgrading further MX68(W,CW) appliances to this version."   MX67C, MX68CW, and Z3C units must be connected to the Meraki Dashboard initially to retrieve an update to allow for proper use of the integrated cellular connectivity. This is most likely to be an issue when bringing the units online for the very first time.     Edit:  Meraki shipped replacement with 14.40 so I downgraded my template to 14.40 and then tried again to add the MX.  Could have been just a coincidence and I did not have the luxury of trying to brick another one so I just downgraded before plugging it in.  But all worked out now but I do have my suspicions on the 14.45 code, which is no longer available.   Thanks all for the input! ... View more

looks like after tunnel lifetime the tunnel is removed. If there is traffic going through the tunnel it would keep the tunnel up. ... View more

Hmm Gotchas hmm Make sure your Meraki is on latest firmware. Some early build MX250/450s don't support /31 addressing until they're updated from factory level (you're running live already so no issues but will put in just in case a factory reset happens). If in Passthrough then your MX may end up doing the PPPoE authentication. If you have a static IP address assigned then best configure the WAN to USE that address rather than rely solely on PPPoE username and password. Check for VLAN tagging; in cases where you use static IPs only and no PPPoE authentication, then tagging must be watched out for on the Meraki. (We used Draytek V130 modems and had to tag the Modem + MX to get it to work.) Ensure your router that is soon-to-be in passthrough, doesn't do anything silly like operate wifi even though its a L2 device. I've seen a few boxes that despite turning it into a bridge, makes all wifi connections L2 (fails to find DHCP.. or worse.. finds them and allows wifi users onto the network without firewall protections.).. Don't ask me how that was achieved 😛 ... magic I guess. Once connection through other device is established run your throughput testing (Security Appliance > Appliance Status > Tools) disregard the result, but watch in the uplink tab to see a good measure of the bearer cct with device in the way. It should be limited to bearer speed and not to 1Gb which is the negotiated duplex between the passthrough router - MX. That's all I can think of for now, sorry if some of them are like teaching grandma to suck eggs. All came out in a big expositional dump XD ... View more

So the network looks like this Internet ---- ISP Hub--- MX64 --- Switch --- AP Is that correct? It may be worth having a quick look at the uplink connectivity of the MX into the hub. Security & SD-WAN > Appliance Status > Tools = Run a Throughput test (disregard the results) Navigate to the Appliance Status > Uplink tab and watch for the packet flood on the uplink that should give a good degree of visibility of what the bearer cct can manage when flooded. Also check to see if you have lots of packet loss when you do this as well (duplex issues). Is the ISP's hub just a modem or is it a router? May be worth checking to see if it's also running NAT or NO-NAT. ... View more

The client registered SIP phones usually have a small outbound connection to the cloud (to listen for incoming calls) and passes keepalives outbound to keep that little connection up and running. Any calls coming in are actually "return" traffic to the SIP phone in question and is therefore "solicited" traffic. SIP trunks usually have a switch that builds what is essentially a VPN tunnel to the Cloud gateways. Phone calls coming in land on that switch and it's responsible to delegate to one of the phones connected to it. Because of this 3rd party VPN these trunks can be a little bit harder to configure and may require assignment of a public IP.   Looks like you have lucked out and have the SIP service that doesn't have any of that complex nonsense. ... View more

Meraki really dislikes ESP and UDP port 500 outbound (from a device behind the MX). It may be worth running a quick Packet capture on the MX LAN, and Internet, just to see if traffic is traversing the Firewall. I have a sneaking suspicion that you won't see the traffic going from LAN - WAN and the traffic is using port 500. ... View more

Actually we did get it working. the best way to do it setup the vpn tunnels before updating to the latest beta software. After you update to the Beta software you can call support and tell them which tunnel needs IKEv2. ... View more

I think  its for the mx inbound firewall rules  when  running no nat mode  ... View more

Will answer the NAT thing first Its a bit of a cheaty workaround to be honest, but you can build as I screenied earlier, its kinda like a transparent NAT. It still translates.. but to itself but it should be reachable remotely and through inter-VLAN routing. About MX15 So you would build the /26 as a private VLAN as above, and then exclude that VLAN from NAT (essentially No-NAT). In this case when your PE forwards the /26 traffic to your Meraki, rather than hitting the NAT boundary and having to be translated, it should route straight through. As seen in the screenshot, no-NAT can be set on the uplink or the private VLAN, essentially relying on conventional routing. From the traffic though, AMP/IDS and all the Stateful FW stuff still apply so there "may" be issues with unsolicited inbound traffic being blocked without some additional config surrounding port forwarding. Not sure if that 1:1 NAT rule that allow remote connections on port numbers constitutes FW rules allowing traffic, need to poke wireshark a bit more and see how it interacts. I know MX15 has this to play with right now, but there is quite a lot of features being tested in MX15, it could be that some of the big changes (like no-NAT) are dropped for general release of that firmware (or pushed to a later stage.) Hope this helps, Just FYI that /26... you could be there some time building 1:1 NAT rules for each IP, have a poke through the API tools and see if there is some way to automate its delivery.... have fun!     ... View more