It would be best to open a case.  From your description this all looks okay.  Feel free to post screenshots of your SGACL and the assignment on both ports. ... View more

- Check to make sure your L2 is okay. So you by checking the MAC table on the switch where you connect  your AP's and see if you find the MAC address of your MX on the correct VLAN. - Check if you are running DHCP snooping on your switches and are blocking DHCP OFFERS/ACKs - Finally if you are sure this is all okay, run a pcap on the ports near the MX or the AP or both and check on port 67 and 68 and see if your DISCOVERs reach the MX and the MX answers with an OFFER. ... View more

Strange, it looks like website is not pushing the fields to the body of the API call.| Did you initially add an iPSK on the GUI or did you immediately start with doing API calls? It is possible that when creating the SSID the first time you need to already have 1 PSK and GPO in place to add this.  And perhaps you can then via API add multiple key/GPO pairs. ... View more

Pinging towards wireless clients usually is not that stable. If  you can see the PHY rate on the clients please do check. Then check on the Meraki side what the SNR of the client is (if you go to an AP status page you can see each connected client and his upstream signal strength which is the SNR).  If it is above 30 dB your connection is excellent.  Then you still need to check the airtime utilization on the channels of the AP on the same page.  Also check which channel the clients are connected on.  If your 2.4 GHz radio is busy and your client happens to be connected on 2.4 then that is normal. Having 150 Mbps speed on a wireless client is excellent throughput if you have multiple clients in that area.  If your application requires low latency and/or low jitter then you will need to check airtimes, QoS tagging on your wireless frames (by doing an OTA capture). ... View more

If your internet circuit is a regular internet circuit then you can only prioritize outgoing traffic from your calls.  So on the traffic shaping page you can create a rule that matches your VoIP traffic and set the outgoing DSCP to EF.  Also do not forget to set the actual contracted down and upload speed of your circuit all the way on the top of the traffic shaping page. However incoming traffic will arrive via your ISP in the order it was sent. So options: - have the phone lines come directly into your network and use dedicated WAN circuits. - have a separate SIP trunk that does not mix with your internet traffic. - apply bandwidth per client limits and set other traffic types to lower priority. ... View more

The multicast forwarding feature is interesting because that is one of the huge feature holes that has been present.  So I am to assume we might be seeing PIM support for MX in the future so you would finally be able to have multicast streams in datacenters being able to be forwarded to branch offices. ... View more

It would make more sense to have both your PC and NAS on the switch SFP+ ports if you really need the juice between those devices.  The switch will forward frames slightly faster than the MX unless you mean your NAS is on a different subnet, then you would need to pass the MX.  But don't worry L2 hops are in terms of microseconds.  You shouldn't notice a difference ') ... View more

If the traffic was sourced from an IPv6 client and WAN2 does not have IPv6 then it is pretty logical it could only use the only IPv6 interface available. If you would test on a client that is IPv4 you should see traffic going out the WAN2 port.  Try temporarily disabling IPv6 on the LAN or on your client and test again. ... View more

Having a vIP is the better option since it smoothes out a failover between primary and spare and allows for port forwards to remain on the same IP.  However it is not a requirement.  In my opinion it is better to have a vIP that is private and NAT'ed than to have physical IP's and not NAT'ed. ... View more

Niiice 😉 ... View more

Using non-Meraki VPN's to tunnel all traffic will most probably not work.  You need to define specific local and remote networks for this. AutoVPN is a different beast.  If you set a default route on a spoke to a hub you can tunnel all local traffic over that for local networks that are subjected to the VPN tunnel.  In that case you would have to tunnel to a Meraki hub that then has a default route to the internet where you can allow or deny traffic using those other technologies. ... View more

You can manually put Meraki group policies on devices that are on Wi-Fi or have to pass an MX.  In case of Wi-Fi you can effectively block them from gaining any access to the network.  In case of MX you can only block their traffic from passing the MX towards other VLAN's or the internet but you can't block local traffic if they are on switches.  Not sure what happens to clients that are on an MX68 direct LAN ports though. To have these kind of blocks you'll need to deploy 802.1X access policies on the switches or try to work with manual port security. ... View more

You don't have a choice.  If you use 2 WAN interfaces you need to have both of them on physical or vIP. Usually if your second provider uses NAT behind it's routers you can use a vIP there too like a 192.168.0.10 for example. ... View more

If you are sure your routing is ok and you did the capture correctly and not see anything on UDP port 1812 leaving the switch, then you should capture the EAPoL frames on the port.  Your supplicant might not be sending EAPoL frames to the switch. ... View more

So if you do the capture on the MX you would have to see it on the LAN side and in the site to site side if you are doing an AutoVPN to Azure.  So then you should also see the packet on the vMX. So if you're are not seeing any packets you have a policy or routing issue.  That means the interface of the switch can't reach the NPS server.  So you'll have to check if the subnet of the switches is included in the VPN and all routing is correct. ... View more

That would be extremely weird since the switch is only encapsulating the EAPoL messages inside Radius and decapsulating in the return.  It does not matter what kind of EAP protocol you are using between the supplicant and the authentication server.  The only thing the switch needs in the end is an access-accept with potentially some AV pairs. ... View more

You're supposed to do a packet capture on the switchport leading to the NPS server while filtering on UDP port 1812 just to see if the access-request message is even reaching the NPS server and if a response is sent back. If you have to do a dashboard capture then you will have to coordinate a test while capturing. ... View more

That's strange because the whole reason the UDP/4500 header is added in front of the ESP header is to get through NAT since NAT on most devices only supports TCP, UDP and ICMP.  The only reason you would get an ESP header right behind an IP header if the two VPN endpoints can reach each other without NAT unless for some reason NAT-T was disabled but then it would not be able to pass through a NAT.   So if you had an MX without NAT then you would never be able to match purely on ip protocol 50 or 51 since that is not supported on the MX.  You would have to allow all IP traffic towards that destination. ... View more

If a device is behind the MX it would be NAT'ed which means the IKE negotiation is done with UDP/500 and the ESP would be encapsulated within a UDP/4500.  So you could match this. However if you would have disabled NAT for this specific then it would send direct ESP behind the IP header and would only match in a rule with Any as protocol. ... View more

When you do a packet capture on port 1812 you should see access-request packets being sent from the switch and access-challenge back from the NPS server. So first make sure the messages reach the NPS server and see if the server responds. If the server does not respond then you will need to look purely at the server (are the switches present in the radius clients configuration?). If you are seeing access-reject messages from the NPS server then you are probably not matching an access rule. There are many more issues but at least start with the basics. ... View more

As of now the tunnels are policy-based VPN tunnels, so no VTI. Tag based failover is the only way for the moment. ... View more

You can use BXD SFP's on Meraki managed/monitored Catalyst switches but on native MS switches it is NOT supported.  The choice of switch is not fitting for this requirement. ... View more