I agree with the confusion since there is a physical MX100 and then they called their virtual one (which indeed does not provide the same functionality) vMX100. They should have called it something completely different like vMX150 or something different so people won't make the connection between the physical and virtual.   With that being said from the main page:   "Virtual MX is a virtual instance of a Meraki security appliance, dedicated specifically to providing the simple configuration benefits of site-to-site Auto VPN for customers running or migrating IT services to an Amazon Web Services or Microsoft Azure Virtual Private Cloud (VPC)."   I've never deployed the vMX100, but my understanding of the product when it first came out was that it is basically just a one-armed VPN Concentrator based on the description above. It is to only be used for the Auto-VPN functionality for remote sites (which is where you could apply all those policies/L3+L7 rules etc.).   Sorry your having this problem =( ... View more

No clue as I've never tried it that way. Not sure if the second switch in your stack (that doesn't have an uplink) will be able to communicate by default with the first switch if you connect the stacking cables. That being said, were talking like 5 ... 10 minutes to do it the right way. If that window isn't big enough I'd have to say your booking yourself too tight lol 😃 ... View more

So to confirm your using NPS on that windows server. Did you put the entire subnet (or specific AP LAN IP which you should make sure is static if your not doing the entire subnet range) that the access points are sitting on?   You might want to review this: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise   Also you need to ensure your supplicant is setup correctly as well. Could just be a client issue with your settings since you mentioned the AP does pass that built in test. ... View more

How do you have the MX64 connected?   Is your WARM-SPARE status showing Active/Ready?   As @PhilipDAth mentioned, if your doing warm-spare, you have to use the virtual IP configuration mode so that the client can use the vIP for it to function. ... View more

Unfortunately the L3 and L7 are tied together in the Group Policy settings. Would be nice if they separated them.   Easiest option I can think of is to create one 'master' Group Policy template that has all your firewall L3 rules copied from your security appliance.   Then just clone that to create custom/specific Group Policy rules that have different L7 policies attached to them.   This will make sure that the clients are still having the same L3 firewall rules, but able to have custom L7 rules so they can access Netflix etc. ... View more

How many access points are we talking about here? How many SSID's?   For stability it's best to have the SSID dedicated to either 2.4 or 5GHz. Don't use band steering etc. I would also recommend static power/channels. Sounds like you did a survey, so those results would help you decide what power level you should have the radio's operating at.   Data rates on 2.4 choose either 12 or 24.  5GHz either 6/12/24. If you have a crap ton of access points then I would lean towards 24. However using 6Mbps might possibly help with retries etc. Those three rates are mandatory per the 802.11-2012 (Section 18.2.2.3) standard. So some old devices (rare though) might act up if you use something like 18Mbps etc.   I would also do a sanity check on every single port that each AP is connected to. Make sure they are setup correctly, native vlans/allowed vlans etc. Make sure your SSID configs are correct on that aspect as well if your using bridge-mode.   If you CAN get everything on 5GHz it's usually preferred, and if a proper survey was completed, this shouldn't be an issue. With the static channels make sure you only use frequencies that your devices support. Those devices might only be able to use UNII1/3 for example, so DFS might not be an option.   If you have an access point in the break rooms/office areas for example, and production clients never really connect to it (warehouse ones that is), you could put those ones on UNII2 band so that any traffic on that AP isn't having any impact on the wireless out in the warehouse with people watching YouTube etc. Just make it vanish like magic  😃   Check the client devices wireless settings. if there are options to force it to only use 5ghz, then that might be the direction you want to go. look at driver version updates etc.   As long as your configuration is solid (sounds like it could use some tweaking), and a proper survey was done, then your at the will of the client gods lol. ... View more

If you rename the SSID to the original SSID name/number it used to have, and disable it, then it won't show up unless you click the 'show all my SSIDs' button.   Unconfigured SSID 1   Just have to get the number correct, left to right is 1 through 15 ... View more

@RR @MacuserJim   Review the FQDN Support here:   https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Firewall_Settings     Important notes:   Make sure your MX is running 13.4 or higher firmware as anything running 13.3 or earlier does not support FQDNs in the destination fields according to the documentation. You will also have to enable 'hostname visibility' for FQDN rules to function correctly, this is under the networks General settings.   I only see 13.33 as Stable and 13.36 as Stable Release Candidate currently. My interpretation of this is that you will have to run 14.X code for putting an FQDN into the destination field for this to work (unless I'm misreading something?) 14.X code is technically beta as of 11/1/2018 so you might want to keep a closer eye on its performance etc., if you decide to move forward with this. I believe there a quiet a few people who are running 14.X for improved AMP performance/reliability without much issue. However, with all that being said. Big giant undocumented and known+expected behavior is FQDN is not supported in Cellular Failover rules, only IP addresses.   This means you will only be able to utilize IP Addresses for now to accomplish what your trying to do.   Below is my best attempt at taking the IP information from Microsoft to accomplish what the FQDN would have done on the cellular firewall rules.   You should be able to copy/paste these so it would be minimal effort to test.     OFFICE 365 RULE 1 13.107.6.152/31, 13.107.9.152/31, 13.107.18.10/31, 13.107.19.10/31, 13.107.128.0/22, 23.103.160.0/20, 23.103.224.0/19, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 111.221.112.0/21, 131.253.33.215/32, 132.245.0.0/16, 134.170.68.0/23, 150.171.32.0/22, 157.56.232.0/21, 157.56.240.0/20, 191.232.96.0/19, 191.234.140.0/22, 204.79.197.215/32, 206.191.224.0/19 OFFICE 365 RULE 2 13.107.6.152/31, 13.107.9.152/31, 13.107.18.10/31, 13.107.19.10/31, 13.107.128.0/22, 23.103.160.0/20, 23.103.224.0/19, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 111.221.112.0/21, 131.253.33.215/32, 132.245.0.0/16, 134.170.68.0/23, 150.171.32.0/22, 157.56.232.0/21, 157.56.240.0/20, 191.232.96.0/19, 191.234.140.0/22, 204.79.197.215/32, 206.191.224.0/19 OFFICE 365 RULE 3 13.107.6.152/31, 13.107.9.152/31, 13.107.18.10/31, 13.107.19.10/31, 13.107.128.0/22, 23.103.160.0/20, 23.103.224.0/19, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 111.221.112.0/21, 131.253.33.215/32, 132.245.0.0/16, 134.170.68.0/23, 150.171.32.0/22, 157.56.232.0/21, 157.56.240.0/20, 191.232.96.0/19, 191.234.140.0/22, 204.79.197.215/32, 206.191.224.0/19 OFFICE 365 RULE 4 13.107.6.152/31, 13.107.9.152/31, 13.107.18.10/31, 13.107.19.10/31, 13.107.128.0/22, 23.103.160.0/20, 23.103.224.0/19, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 111.221.112.0/21, 131.253.33.215/32, 132.245.0.0/16, 134.170.68.0/23, 150.171.32.0/22, 157.56.232.0/21, 157.56.240.0/20, 191.232.96.0/19, 191.234.140.0/22, 204.79.197.215/32, 206.191.224.0/19 OFFICE 365 RULE 5 23.103.132.0/22, 23.103.136.0/21, 23.103.144.0/20, 23.103.198.0/23, 23.103.200.0/22, 40.92.0.0/14, 40.107.0.0/17, 52.100.0.0/14, 52.238.78.88/32, 65.55.88.0/24, 65.55.169.0/24, 94.245.120.64/26, 104.47.0.0/17, 157.55.234.0/24, 157.56.110.0/23, 157.56.112.0/24, 207.46.100.0/24, 207.46.163.0/24, 213.199.154.0/24, 213.199.180.128/26, 216.32.180.0/23 OFFICE 365 RULE 6 23.103.132.0/22, 23.103.136.0/21, 23.103.144.0/20, 23.103.198.0/23, 23.103.200.0/22, 40.92.0.0/14, 40.107.0.0/17, 52.100.0.0/14, 65.55.88.0/24, 65.55.169.0/24, 94.245.120.64/26, 104.47.0.0/17, 157.55.234.0/24, 157.56.110.0/23, 157.56.112.0/24, 207.46.100.0/24, 207.46.163.0/24, 213.199.154.0/24, 213.199.180.128/26, 216.32.180.0/23 OFFICE 365 RULE 7 23.54.148.117/32,23.56.200.254/32     The rules above are the super specific ones that I could come up with based on the Microsoft document from the link earlier mentioned. However a good deal of these are duplicate IP's etc. So if you wanted to stream-line it, and ignore the destination port specificity, then you could do this with destination port of ANY and call it a day     OFFICE 365 RULE - ANY DST PORT   13.107.6.152/31,104.47.0.0/17,111.221.112.0/21,13.107.128.0/22,13.107.18.10/31,13.107.19.10/31,13.107.9.152/31,131.253.33.215/32,132.245.0.0/16,134.170.68.0/23,150.171.32.0/22,157.55.234.0/24,157.56.110.0/23,157.56.112.0/24,157.56.232.0/21,157.56.240.0/20,191.232.96.0/19,191.234.140.0/22,204.79.197.215/32,206.191.224.0/19,207.46.100.0/24,207.46.163.0/24,213.199.154.0/24,213.199.180.128/26,216.32.180.0/23,23.103.136.0/21,23.103.144.0/20,23.103.160.0/20,23.103.198.0/23,23.103.200.0/22,23.103.224.0/19,40.104.0.0/15,40.107.0.0/17,40.92.0.0/14,40.96.0.0/13,52.100.0.0/14,52.238.78.88/32,52.96.0.0/14,65.55.169.0/24,65.55.88.0/24,94.245.120.64/26,23.103.132.0/22,23.54.148.117/32,23.56.200.254/32   I have no clue if this would work or not work. Only one way to find out is to test it 😃   Good luck ! ... View more

@RR @MacuserJim Ironically, I always see OFFICE365 as one of our biggest hitters for bandwidth consumption. Its a constant complaint on Microsoft forums about how much bandwidth the constant syncing it does between client to server over the Internet. People hotspot bills getting slammed etc. I've found no solution for this. With that being said, if you WANTED to try something. The only thing I could think of is to create an API script, that would create a new L3 firewall rule, that would allow the IP Addresses that OFFICE365 uses, and then deny any any at the end. That would do the job in theory. their insane IP list is here https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges This would be a manual process though. You'd basically have to act on this yourself once you get an email alert from the dashboard that your primary link went down. So you would just update the L3 firewall rules via API. When WAN1 comes back, run another API script to set everything back to normal. I don't know how you could automate this anymore unfortunately. ... View more

@MacuserJim Not a bad idea, however, I don't want it to function at all because I don't want any traffic from a BYOD device using the specific WAN connections for corporate use. So blocking 100% is the only choice to ensure this. ... View more

I don't see any option for using the TAGs, so I must be missing something. Not sure that would solve it though. I understand the false positives will happen, its not perfect. So I know I can't prevent it, but just want to take action when it does happen. I'm thinking there isn't any easy way to do this other than what I've been doing which is wait for a complaint or check it manually occasionally =( lol ... View more

What version firmware is the MX67 running?   I can test this when I get home on mine, but you might want to open up a case with support in the meantime, as this is a relatively new model and it might be some sort of software limiter/bug. ... View more

Actually now I know why it didn't register. I thought they were using the word 'uplink' as in 'wan port'. Not upload traffic itself. Just like oh ya plug it into the uplink port. etc. Oh well lesson learned thanks again ! ... View more

Aaaaand its in the very first sentence. I glossed right over that lol. They should underline it and make that word bold rofl. Thanks again ! ... View more

@PhilipDAth Phil, so just to clarify. The Priority rules (HIGH/NORMAL/LOW) only apply to Upload (outgoing) traffic? If that is true then it makes sense, but I feel like an idiot if that is true because I don't remember reading that anywhere lol. That is like wearing a hat and going 'where did i leave my hat' lol. I take it then if I want to actually control YouTube to 1Mbps like mentioned above, I would need to do an actual traffic shaping and set the throughput level manually. ... View more

@MacuserJim I happened to just test this last night. Set the MX to 7Mbps on WAN slider thing, and when I do speedtest this holds true. Maxes out at 7Mbps Set one rule, for YouTube to be LOW, which I interpret as meaning it will only pull 1Mbps (1/7 of the 7Mbps). No other rules. I know that these priorities only kick in during saturation, so I started download Ubuntu ISO which maxes out the pipe at 7Mbps. So then I start a YouTube video and the results every time is they split 50/50, each pulling 3.5Mbps. I was under the impression that I would see the Ubunutu ISO pull 6Mbps, and the YouTube pull 1Mbps Either I'm misunderstanding something about how it is supposed to work, or my config is wrong. ... View more

I tested this at home and I was able to get past my MX and onto my AT&T router login page without anything special. MX configuration is standard out of the box.   It would appear that maybe you have some sort of rule or something causing this. Assuming you've rebooted as well. ... View more

Traffic shaping policies perform the rules in the order to which they appear, top down. Like firewall rules.   Move Rule #2 up so it becomes Rule #1 and try again. ... View more

Try reaching that using Incognito mode   I've had some trouble myself with the local status page being flaky sometimes ... View more

Spence,   For my solution you will need to have your primary ISP as WAN1 (your DSL) and your secondary (LTE) as WAN2. Then my setup should function as long as you have support make the 'cell firewall rules' apply to WAN2.   However if your doing Full-tunneling then all your traffic will go over the AutoVPN to your HUB, so any 'local' internet usage will go over that and you can't block it (that I'm aware of).   You would need to do split tunnel and then only send intra-net (internal) traffic over your AutoVPN tunnel. This way Internet traffic will drop off locally, either WAN1 and WAN2, and then with my method you can block guest to Internet over WAN2 (LTE) when it kicks in.   ... View more

Forgot to mention that you will need your primary uplink to be WAN1 for my solution. I see original poster has WAN2 as primary, so just clarifying. ... View more

This can be done, and I do this myself as my backup LTE is a hotspot box that has a LAN port that plugs into my firewall, so it is not USB based.   This is actually easier than you think, however you will need to contact support.   One of the gripes I've always had about the firewall section on the MX is they do not separate WAN1 and WAN2 firewall rules. They combine WAN1 and WAN2 into a single 'Outbound rules' section. They should separate them into two groups so that you have granularity control over it.  Rumor is that they are planning on doing this in the future, but we'll see. However, if you ask support, they can do something behind the scenes, so that the 'cellular' firewall rules are actually applied to WAN2   So when WAN1 goes down, the cellular failover rules 'append' themselves up, to the outbound rules above. So just think of the 'cellular failover rules' section as 'WAN 2 outbound rules'.   Here is an example of my setup (i took out any IP info to make it easier)   ... View more

Thank you very much for the response Cameron ! ... View more