This is general L3/L4 firewall policy. It does take about 20 seconds for a rulechange to actually pushdown on the MX. Take care of the order of your access rules. Make sure your interVLAN policies are at the top before allow rules that have any as destination. I personally take this approach: List all your interVLAN policies up top and make sure their ordered by source VLAN so it makes it clear to read.  Always end your source VLAN rules with a rule that denies any traffic from that VLAN going to any other VLAN or local RFC1918 addresses. That way you are sure you won't have any fall through to the lower rules that inadvertently allow traffic between VLAN's that is not intended. And below the interVLAN place your general LAN to WAN rules like TCP/80,443, UDP/53, etc etc. ... View more

I'm not sure you need a separate vNet(because this needs peering) but at least you need a different subnet so the vMX lives alone on it's subnet and can only go default gateway towards the Azure routing table for routing both to other subnets in Azure or outside to the internet for the AutoVPN traffic. ... View more

The Meraki vMX is supposed to be on it's own subnet as a solo device.  It can only default route out for both the VPN tunnels to the branches as the Azure routing table to reach other networks.  You're not supposed to  have a Palo Alto directly as a gateway on that same subnet. ... View more

Your pure aggregate config and flags seem correct.  VLAN config of course is another thing.  I recommend using an unused VLAN ID as native VLAN on the port leading to the FGT and then on the FGT not defining any IP on the aggregate itself but only on VLAN interfaces on that aggregate. We do have a few customers that are running MS, MR but have an FGT as gateway and usually we do aggregates to those and have not yet run into this issue. ... View more

It's the same as with disconnecting an active client VPN session.  We need to have the ability to monitor and terminate existing flows. ... View more

For me this version is a no go.  I have a few customers that are using Radius Filter-ID for Cisco Secure Client VPN filter and the enforcement of the rules only seems to be working on ICMP traffic. ... View more

Another update on the case.   Meraki helped me get back on the MX18.107 software train.  And from the first tests it seems to work immediately. So I believe the MX18.2x train has this issue and it should be included in the issues list. ... View more

The issue is that the MX at this time does not support the other or managed config flags in it's RA's which is a shame. From the documentation: As of now, we only support SLAAC on LAN with limited RA options (like prefix information, MTU, source-link layer address). We do not support DHCPv6-NA server functions. It has been quiet for quite a while on the IPv6 front within Meraki so I'm curious where they are at.  I also recently asked about when the IPv6 support will be there for HA-pairs of MX devices.  The answer was "not this FY".  Which to me means we won't be seeing those needed features until MX20.x. I guess it's time to keep nagging some guys in Cisco for this 😉 ... View more

Do you have this issue on all ports? You could easily check if Meraki is actually reporting this by just capturing the snmp packets and see if it is actually reporting that. It might be a reporting bug of the Meraki switch.  Maybe test if a reboot fixes it and if so do a bug report. ... View more

Your Meraki will do that automatically. If your primary selected WAN is down it will try to form a VPN over the other one. However in that case  you must have a configuration on the FTD side that can enable the VPN that way.  I don't really know if that is an easy task though. I believe in old ASA code you could just use another tunnel-group and have your crypto map statements changed.  However this needs to be manually entered or somehow scripted to change your config when it happens. ... View more

You can ofcourse tweak it if you really have a noisy environment.  But you ought to have to check what exactly is going wrong.  Is it a coverage issue or is it a airtime/interference problem. RX-SOP is a tool meant to be used in busy environments like office buildings with multiple customers on every floor or high density areas. Usually when RX-SOP is used the values are around -82 up to -75 dBm.  Going higher than -75 dBm will not give any more advantages while even worsening the situation. So yes you can play with it but I would urge you to actually go and check what exactly is going on. ... View more

Please check your eventlog on both ends if both ends are actually communicating with each other. I believe you will also have an issue with the IKE-ID. Since at least your MX is behind a NAT the IKE-ID your MX will give by default it's local WAN IP as IKE-ID and this will not match it's public IP address so the other side will reject your authentication. ... View more

Small typo: You mean through the ISP router. 😉 ... View more

In that case you should be checking the PHY rates on your endpoints if their datarate is high enough. And you should also check the airtime utilization on the channels of said AP's. You could have the scenario where there are simply to few AP's at that location and by removing the RX-SOP you effectively allowed the clients to remain on an AP at a lower datarate. Other possibility is that the AP now hears more interfering signals from other sources on the same channel and is delaying it's transmissions. In the first case you could just check using the clients. In the second case you may need to have a small survey at location with correct gear.  But start with checking dashboard if you see any interference on the AP's. ... View more

No problem, glad it's only that little thing 😉 ... View more

Do you already have the upstream interface + 0.0.0.0/0 route added to the new switch?  You need to have this done before adding any other new interfaces.  Maybe it would be better to create the interface separately on the new switch with a custom IP before removing from the existing switch. ... View more

The CA cert you uploaded is for your client authentication right? What are you using as Cert for the Anyconnect session itself? If you let dashboard manage the cert you have to connect using the dynamic-m url instead of the public IP. The client authentication cert is separate from the Anyconnect server certificate. ... View more

I do remember from a few years back that I had a hotel with a TV system that was multicast.  The overlap where both streams were present on a port were minimal.  I  however don't remember if the switch sent out IGMP group specific queries when the tv sent a leave for that channel. It's quite hard to troubleshoot this without having proper gear that can quickly switch between streams. ... View more

Will both Open networks and Enhanced open networks be able to take advantage of this?  Else we won't be able to use it for 6 GHz networks.   How about WPA3 support for local auth using certs? ... View more

This may be something to keep nagging to the sales rep. ... View more

That won't do  you any good.  The OSPF implementation on the MX is not used for internet bound traffic but only for SD-WAN.  And it will take in the routes and spread them to branch offices.  It will not advertise anything in the local network. ... View more

It will work.  It is however best practice to fully close your stacking loop.  So do purchase another stacking cable.  These are relatively cheap anyways. The reason for the second stacking cable is to have redundancy and extra bandwidth in the backplane between the switches in the stack. ... View more

I haven't checked that one yet.  Usually stuff like this is on the client page. What you could do in the meanwhile however is to set a shorter session timeout so the sessions kills itself eventually. That would be a good tool to build into the MX status page. A live get VPN sessions and then some buttons do disconnect. ... View more

It is very important if you are using the 2.4 GHz band that you DO NOT DEVIATE from the 1,6,11 scheme.  The problem with 2.4 GHz defined channels is that they are only 5MHz apart and 1 OFDM transmission is 20 MHz wide in the 2.4 GHz band.  That means  you are causing adjacent channel interference which is very bad. First you'll have to make sure your deployment is fixed on one band.  So if your deployment of that SSID and system is only supposed to work on 2.4 GHz then don't transmit the SSID on the other bands so you avoid interband roaming.  And conversely if your deployment is made to work on 5 GHz try to only transmit that SSID on 5 GHz. Then you can start your troubleshooting process. - Check RF:  do you have enough coverage, are you using RX-SOP that is too aggressive, do you have an active interferer at that location?  You can try to check the dashboard RF page for first checks before sending someone onsite with a measurement device like a sidekick or an offering from another vendor. - Check rogue AP's: do you happen to have another AP system that is sending the same SSID in the air with perhaps a different setting?  Check dashboard on the air marshall page. - Check logging in Meraki dashboard, could be an indication (roaming analytics, time, DHCP and DNS log. - Check that all AP's in that area have the same switchport config and all VLAN's are available at that switch. - Last resort: over the air packet captures to see what is going on. ... View more