Ok, then you need to create a new RT, add 0.0.0.0/0 pointing to Virtual appliance and the AZFW IP. Then set the option to propegate gateway routes to NO on the routing table.   Attach that to your workload subnets.   The reason (i think) as to why you can ping from a meraki spoke to workload, but no the other way is because from the spoke, traffic goes to the vMX, then to the AZFW. Traffic is then allowed and forwarded to the VNET and the VM. Return traffic does NOT go through the azure firewall and instead goes directly to the vMX. When you initiate a ping from the workload VM this goes directly to the vMX and to the spoke. Return traffic is then send back to the vMX, but then is sendt to AZFW which does not have an active session for this traffic flow, which then results in traffic getting droped. ... View more

Is this the workload route table? Looks more like the VMX route table to me. ... View more

Great! On a virtual machine in your workload VNET, can you select the network card and look at effective routes? Post the screenshot here and i will take a look.   This sounds like asymmetric routing through azure firewall. ... View more

Post your VPN tunnel config.   Also, consider moving from ipsec to AutoVPN. Much simpler, and considering that you already have a vMX in AWS this would be a costless improvement. ... View more

I see that i formulated the answer badly. In your VMX RT you should only add your workload vnet prefixes and point them to azure firewall. I see that i mentioned all VNETs in my previous post... i meant workload vnets. Sorry about that. ... View more

Topology looks good.   Is the BGP peers up? You must add BGP peers to both route server IPs for BGP to come up. How does your vnet peering for the workload vnet look? You need to tick a few boxes. The one where use peer gateway or route servers is the important one.   As for networks to add to your RT. Usually only workload networks peered to your hub. But you can point hub networks to the firewall as well if you want to firewall it. I usually choose to only add workload vnets. ... View more

  The "ghost" in the network rack. One spooky day during a large fullstack Meraki installation we hears rumors about a creature haunting the network racks. Turns out it was just a mouse that added to much fiber to its diet.   ... View more

Depends on your architecture. But VWAN can get expensive fast. If you just plan on using meraki as a vpnc which acts as the only entrypoint to your environment i would say that VWAN is overkill. Also, for existing azure environments the route server setup is easier to "shim" in without uprooting the entire architecture. Just my two cents 🙂 ... View more

No issues with the 48 port switch. But 4 MR 57 on a MS130-8-P might be pushing the POE budget a bit further then i would be comfy with. The MX65 only has 60W poe capacity. The MR57 can draw up to 40W each.   Consider an MS130-12X or MS130-24P. ... View more

Hey, I see. First question. Did you add the route server subnet to the route table pointing to AZFW? If yes, make sure to allow tcp 179 through the azure firewall. If no, it should work by default unless you got security groups blocking.   Also, in the Meraki dash, make sure to sett EBGP Multihop to 5 or something. The route server is never 1 hop away in azure. If you route it through Azure FW you might need to increase the number. Increment by 1 until it works.   Check those first. If the issue persists check back in and we can look at it further 🙂 ... View more

Yes this works. But keep in mind that if the primary WAN on MX1 goes down, the secondary WAN on MX1 will become active, not WAN1 MX2. If your connection is slow this will not be a pleasant experiense for your users. ... View more

I see. In that case im not sure what the issue could be. The liquid template in my example posts works just fine. Try to copy that and see if it is just a typo somewhere. Keep in mind that the template is made for service now. Your system might have other requirements.   Could it be an issue with the reciever? What happens if you just send a webhook test to webhook.site for example? ... View more

Yes. This is due to azure routing logic with possible Vnet gateways and azure route server. If you designate a spoke as your vMX VNET and peer that to your hub VNET you will run into limitations with route learning. Best to pile network functions in the hub VNET. ... View more

You create VLAN profiles under network-wide > VLAN profiles. There you can add VLAN name to VLAN ID mapping.   After that you need to return the VLAN Name form your RADIUS server to the Network Access Device during client authentication.  ... View more

You need to enable and configure VLAN profiles for dynamic vlan assignment.   VLAN Profiles ... View more

You may need to convert the string to base64. Take a look at my reply in this thread. Also, templates can be org wide, but there is a few additional hoops to go through. Those are also outlined in my post. Hope it helps 😀 ... View more

You are either having issues with some of your service providors or it could be a temp. issue with the meraki VPN registrar. I would open a support ticket and have them check if the issue persists. ... View more

Congratulations to all, and thanks you for the recognition! Always happy to help 💚 ... View more

I have done a few deployments that matches your scenario. Here is the key takeaways.   Before deploying the vMX, make sure that YOU create the network resources, not the vMX Wizard. When you do this you gain the ability to apply route tables and security groups to your vMX subnet. This is vital for your scenario to work. Place the vMX subnets in your hub VNET where your AZFW and/or Virtual network gateways are located. Create a route table that you will apply to the vMX subnet. This table should include all your VNET ranges. Keep in mind that you can not summarize, you must enter the VNET address ranges using the exact CIDR notation, then point those routes to your Azure firewall. Then create a new route for 0.0.0.0 with next hop internet. This guarantees that the vMX reaches the internet in the intended way, meaning through your instance bound public IP. Make sure that your workload VNETs (spokes) sends all traffic to the Azure firewall. In this scenario the AZFW will act as the Routing Hub for your setup. It is vital that the traffic flows through AZFW and vMX are symmetrical.   Now, there is two ways to solve routing from Azure to your Meraki Auto-VPN peers. One is to use a routing table on the azure firewall. This is fine if you have a simple deployment with few subnets. If you have a large deployment i would strongly recommend that you use Azure Route Server unless you are using Azure vWAN.   Place the Azure route server in your hub VNET and enable BGP in your Meraki Auto-VPN. Then add BGP peers to Meraki and ARS. Remember to add the azure route server subnet to Local Networks on your vMX in the meraki dashboard. If you do not do this BGP neighbors wont form.     Regarding your Virtual network gateway question. No you do not need it unless you want express routes. But i would still recommend it if you are planning on running 3. party VPN tunnels. VPN tunnels scales better on a Virtual network gateway rather then terminating them on your vMX.   Hope this helps!   Edit: When deploying the vMX i recommend that you select an Availability zone and not None. This changes your Public IP SKU from Basic to Standard. Basic PIP SKU is getting removed. This might save you some headache down the road 🙂 ... View more

Licensing is quite simple. You got Advanced and Enterprise. Beyond that licenses are not model specific. 1 AP license covers one AP, simple as that.   As for AP models i usually settle for MR44 for indoors and MR76 for outdoors unless a customer has some specific requirements like Wifi 6E or super high density.   For deployment models i almost always go for the "default" mode of using VLAN taggs pr SSID. Read FlexConnect. In some cases customers need all wireless traffic to be backhauled to a datacenter. For that you would need an MX located in the DC to act as a droppoint for this traffic.   I recommend that you go through Meraki FIT and CMSS certification track before you start deploying. https://community.meraki.com/t5/Meraki-Certification/ct-p/cmss https://community.meraki.com/t5/Meraki-FIT/ct-p/merakifit   Hope this was helpfull.   ... View more

No issues running adv on MX and AP and enterprise on switches. Advanced for switches unlocks adaptive policy (trustsec). ... View more

Not possible to my knowledge. Also you would run into issues with recursive routing.   Were i you i would look into moving this NAS to another service like cloud or maybe a synology NAS that you connect to the LAN instead.  ... View more

Need more info about your setup before anything can be recommend. But this should be easy to solve with just plain routing. Advertise your VNET to the Azure IPSEC tunnel and further down to the MX250. BGP or static, both get the job done. ... View more

Well, in the dashboard you configure your radius server pr network, template or globaly. Point to the NPS IP, create a shared secret and off you go.   Remember that the radius requests originate from each devices management IP. You need to make sure that NPS accepts radius requests from those IPs.   Other then that it is mostly client, intune and NPS config. ... View more

No problem. This should answer your ospf question. There is quite a lot of limitations. Especially when it comes to route advertisement. BGP is more flexible.   MX OSPF    You can do Auto vpn across rfc1918 space, but for that to work both site A and B MX must exit to the internet on the same public ip. But for it to work this interface MUST be connected to WAN.   If the ISP can provide an internet access for your WAN interfaces on each site i would do that. It just simplifies the setup. If you want meraki sdwan you must terminate the vpn tunnels on the MX.   In all honesty it does not sound like MX was the correct option for your router replacements. I think you should rework the design to fit the meraki standard. Its hard to mold meraki into something that it was not ment to do.   Another option is to wait with the MX untill you get site B gear. You can deply everything else. Then when you are ready you can build your sdwan. ... View more