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

Oh forgive me on that, moving the box into concentrator mode turns it stateless and services disappear in favour of inbound FW rules configuration. I've tried testing with a Meraki MX as an edge. Even if I disable local status page, if the services had my IP address or ANY in it, and I dropped the edge IP or hostname into a browser, I can gain access to the local status page of the Meraki. So the local status page function just doesn't seem to work at all and seemingly the only way of blocking remote access are FW rules. Even tried with Local status page enabled but the subsequent control "Remote Status page access" disabled and still was able to resolve access to the Meraki local GUI.  Is this a fault or feature of that network-wide control then? 🙂 ... View more

Double check here  Security & SD-WAN > Firewall Adding IP addresses here allow your to remotely land on an MX's "local" status page. In addition, the local status page for a Meraki device uses a range of ports beyond 80/443, 8080 is one and there are a few others. You may need to block a wider range of ports to prevent access to the device's page. ... View more

Hmm sounds like an unhappy customer for sure. What Firmware version is the Dashboard you're connecting the MX too running at? I wonder if moving from factory default firmware; bootstrapping up to active firmware versions has bricked your box and could of sworn I saw mention of this happening rarely on some of the same model box you have. That's beta firmware code though not RC or standard candidate versions. Let us know how you get on, looks like its a call to Meraki to have a nose about. 😞 ... View more

1.Both WAN 1 and 2 must have internet access for this to work? In other words: WAN1 and 2 must be online first? What if my MPLS link does not have internet access? Each WAN uplink conducts a connection monitor (CMON) test to confirm the availability of the port. One of those tests is to resolve a DNS and to see if the Dashboard can be reached. Should this fail the port itself will fail. Any traffic will be pushed on the secondary link only and not utilise the primary link at all. Your options here are an MPLS cloud gateway for breakout, or some kind of hub site with a cascaded solution to allow for central internet breakout. Or you could put routers/switches in front and using pbr to push CMON traffic up to an internet-facing route. There are settings being tested for private networks, but no guarantees that VPNS would survive even with that.. for now. 2.If I enabled NONAT on WAN2, I can't see "Inbound Rules" enabled under Firewall options. But as per the guide I should do a deny any any. What's the expect option? Meraki MX will still behave as a Stateful Firewall even in NONAT configuration. So unsolicited inbound traffic will be blocked. You can contact Meraki to make the MX stateless, in which you gain control over the inbound FW rules (default to allow all so better be quick to apply deny all when it gets changed over) - I think this requires the MX to be running beta code though and the Meraki TAC advise against it. 3.To send traffic to WAN2, I need to apply PBR under Uplink selection -> Flow preferences right? Not to use static route? My idea is to force certain MPLS subnets/routes to go via WAN2/MPLS. Yes, Flow preferences or VPN SD-WAN policies to control traffic flow to uplinks. Allow the MX to do its job and manage your connectivity at this level rather than large static route policies. <- That's just my personal opinion though, matter of taste 😛 Other question: I can't terminate MPLS/EBGP on MX because EBGP is on BETA and only supported on concentrator mode right? Correct, concentrator only.. for now. ... 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

As Chris said, Your HA spare is essentially a paperweight that only does connection tests outbound and isn't even Switchable until it becomes active where all the config (save the uplink IP addressing) is copied across onto it. You could use the Meraki MX equivalent of HSRP and have a floating IP between the Primary and Secondary MX, and point both your tunnels at that address shared between those two boxes. ((this is assuming that you have a single site with 2x MXs on it and they point towards a remote Azure Site.)) Problem is then you'll have to ensure that bot uplinks physically sit within the same subnet, AND there's enough IP addresses to make a shared IP address for the primary and secondary device. In essence both of your tunnels from Azure will terminate on the Primary (through the shared virtual uplink IP) and when primary drops then the secondary will get it instead. Alternative 2 Create a separate network for your secondary device, purchase another license and run each MX separately. This will put a lot of heavy lifting on switching estate sitting behind the MXs (as they will have to path select which MX) and MX VLANs will also get a bit more of a headache. Sorry to be bearer of bad news.  ... View more

We deploy many on bearer circuits that use ethernet presentation. They serve as CE (edge devices) suitably enough, and maybe one day they'll even come with a DSL connection as well *fingers crossed* It's a reasonable UTM, so best efforts security FW, and some LAN capabilities to manage the rest of your estate using VLANs so all should be good. I am sure we can pitch in with ideas if you need. ... 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

vMX are really only available on AWS and Azure at the moment as VMare instances, although I am sure something will be in the pipeline to expand that. Auto-VPN from Meraki dashboard could handle connections into the worldposta cloud. Details on the site mention VPN capabilities so there should be no issues with that connectivity. Of course Auto-VPN can only really sort out your Meraki gear and VPN config on the cloud would have to be with their support. It won't be pretty, but it will work.  P.S  Consider the throughput and max tunnel count the worldposta VPN can support Tag your MX branch sites accordingly to assist with excluding certain networks from all attempting to mesh with the worldposta cloud (if it can't support it) ... View more

There seems to be a fair amount of alarm suppression happening (event log presentation) Noticed that something like blocked malware is about an hour lead time until it shows in logs and sends alerts. 15 minutes (approx) for cellular up/down Down is 5-10 minutes Failover approx 5mins It could mean that these alerts have different values, or that the boxes when getting lots of event log hits, place notification on a lower priority and that accounts for the delays in alerts being sent and logs being populated ... 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

Hi,   So that LAN IP addres range is publically routable (as in RIPE address right)? Do you have an issue with building a private VLAN range (say 192.168.x.x) and mapping? Otherwise you'd need to do something like this. Build a private VLAN in that /26 range as you stated. For each IP address you want to use in that range build a 1:1 NAT rule setting the public and private IP to be the same. NAT still happens here but if you have your client with that IP address then "whatsmyip" will show the correct public address, and inbound connections will be allowed to that device. NoNat is only in Beta for MX15 right this moment so it may require workarounds like this for you to make private VLAN ranges publically routable on the MX You'd have to do this rule entry for each IP address within that 26 range you wish to utilise. The 1:1 NAT rules are explicit IPs only. ... View more

Are you certain the VPN tunnel is getting to Phase 2 IPSEC here? From the piece you've copied all I am seeing is phase 1. Is there a chance you could snatch us a packet capture of traffice from Internet outbound? Might be some indications there why its not stable. ... View more

Might need to ask a couple more questions here. Are you pointing the non-meraki VPN tunnel to the Azure public IP address? Are the pre-shared secrets, timeouts, and other configuration options matching what you have setup on Azure? What happens to the IKE packets outbound from the Meraki MX? Are there any return packets/traffic from the Azure address range? Azure private LAN IP ----- Azure public <------> Meraki public ----- Meraki private LAN IP range Are there any rules for port forwarding or 1:1 NAT on the Meraki MX? Sorry for the million questions, just need to picture a bit more of what actual config is on these respective devices. ... View more