We had the same NO-PROPOSAL-CHOSEN error on the remote side of the Site to Site VPN.   We have found that with Load Balancing enabled and Active-Active AutoVPN set to Enabled, the Non-Meraki VPN peers can still only be established on whatever interface is set as the Primary uplink on the SD-WAN & Traffic shaping page.   We resolved the NO-PROPOSAL-CHOSEN error by using the correct Public IP of the MX on the remote side of the tunnel.   ... View more

To give hopefully some clarification here: Routed tunnels are built off generic traffic selectors, so they'll take whatever gets routed to them so long as a matching route exists. This does indeed mean that yes, routing between Non-Meraki VPNs and AutoVPN is possible now, in addition to being able to full-tunnel traffic from a Non-Meraki site to a Meraki one. ... View more

I have always found the packet capture a bit flakey, sometimes just not showing any packets at all and then you refresh/come back 5 minutes later and it works! ... View more

If you don't want to, or can't implemented pushed MFA, another option is to enable certificate authentication as a second factor (or indeed third factor since it works with pushed MFA as well). To do that, you'd need a local Certificate Authority (which your Domain Controller can serve as), then generate a self-signed root cert, which you'd upload to the MX. It doesn't need to be from a commercial or otherwise publicly trusted, so long as you trust your own organization to serve as a secure root for a chain of trust.   From there, you can then just start using that CA to sign certs, and install those onto your client hardware to serve as a means of authenticating your client devices to the MX. It's a bit more work, but I would also highly suggest you find a way to provide certs with unique Subjects/SANs to each of your client devices, that way you're not having to reissue a new one any time you need to terminate someone's VPN access. ... View more

Since you have an MX84, it's unfortunately not possible for you to implement what you want owing to firmware limitations. On newer platforms that can run the MX19.1 branch, what you're asking for is possible now with routed-mode VPNs, though that also requires the use of BGP to signal a return route back across the tunnel for any clients on the non-Meraki side of the tunnel ... View more

Closing off my experience on this. The MX75 I opened a support case for rebooted for a different reason. However support confirmed that a different MX75 had encountered hardware panic reboots and required replacement. ... View more

No, it remains. ... View more

Hey folks, This is a well-known consequence of DTLS negotiations failing: https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116881-technote-anyconnect-00.html If it's not a huge issue to your users, it's relatively harmless to leave it be, but if you want to fix it, make sure your appliances are reachable on UDP 443 ... View more

Hi, For L2TP I had a chat with Meraki SE and he mentioned the group policy will be tied to the VPN client virtual MAC address and not the username and virtual MAC address can change and if it changes then group policy wont get applied? ... View more

Hello - we have seen this issue across multiple locations.  We have a combination of MX68s (approx. 100) and an MX450 across multiple circuits, providers, etc.  We had the same L7 country code block list for all locations but not all experience the issue making it harder to troubleshoot.  In general, I understand other countries might be involved in Internet traffic but we have not updated these rules in years and the issue seems to have surfaced over the past few months.  The fix was to delete the L7 rules from the affected firewalls and I have slowly been adding back countries to the block list.  Also, it would be nice to be able to report what rule is blocking traffic but apparently (according to Meraki support) we are not able to get granular detail.    The MX68s are generally at MX 18.107.7 and the MX450 is at MX 18.107.9.   I should also mention that one of the sites inbiz.in.gov did fully load after about 4 minutes.  Once we removed the L7 rule it loaded in about 1-2 seconds.  The HAR file did not indicate any sites external to the US that I  could find. ... View more

You need both, because the preshared key is what authenticates your users' devices and your MX to one another. The username/password is required to authenticate the users themselves ... View more

Note that the MG21 is having issues (some firmware near future should fix this though)..   MTU size is default 1280 on a MG21. Call support for a patch they can run. So the MG21 will start to use MTU1500. ... View more

Packet loss could easily be the cause of reduced performance though ... View more

Recently detailed in : https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Behavior_during_Connection_Loss_to_Cisco_Meraki_Cloud ... View more

To answer your question simply, no we have not.   We changed Intrusion detection and prevention setting from prevention to detection.  This was to ensure we weren't asleep at the wheel allowing threats to pass through.  Our findings were we were getting little to no benefit from this feature (as evident from the event logs).  Thus we've left it as detect only.     Anecdotally we also observed that MS Teams meetings became more reliable with less garbled audio and dropped connections.    ... View more

Have you tried change the ip setting in the starlink  webpage?  change it from default  to "Private IP"     ... View more

I appreciate the technical explanation. Thank you for taking the time. ... View more

Make sure you are allowing all traffic from your sonicwall IP address in the upstream device that is NAting to your MX. I had a though time deploying a Meraki vMX in Azure, since Azure gives you a NATed public IP address.  The biggest issue I had was that nowhere in the deployment documentation it's mentioned that you must allow all traffic from the IP address of any none Meraki peer you want to establish a VPN connection to in the Azure Network Security Group assigned to your vMX. ... View more

To be explicit here, yes, ECH will pose a problem for some features on MX. Explicitly, Content Filtering relies on being able to see the domain the client is attempting to communicate with, which is contained in the Server Name Information (SNI) field of a TLS header during the initial handshake.   This works just fine for TLS 1.2, and TLS1.3 when ECH is NOT in use, but any extensions to TLS1.3 that obfuscate this information will prevent it from functioning. ... View more

I don't recommend it, I had several problems with version 18.x. ... View more

Got links from Support describing requirements for the certificates and have now set up a test with self-signed certificates. Seeing that things work if the certificate has the correct setup. This is anyway client authentication so the client needs private keys, remember to use a template that has client authorization as its use.   https://documentation.meraki.com/General_Administration/Other_Topics/Certificate_Requirements_for_TLS   https://learn.microsoft.com/en-GB/troubleshoot/windows-server/networking/certificate-requirements-eap-tls-peap ... View more

This is not true unfortunately - MX64s, 65s, 84s, 100s, 400s and 600s do not support the use of TLS for management traffic, and there's no way for support to override this (due to reasons I'm not at liberty to disclose) ... View more

Apologies for delay in responding, I have been on hols. All looks good now, thanks Alex. ... View more

The customer replied saying that he would need the IPs for each domain and that they can’t place wildcards in the middle of a multilevel subdomain. This is the documentation from LogMeIn with the * as a way to allow many domains. Is there a solution for this, you think?   ... View more

It was a patience issue. Took about 15 to 20 minutes and things were being blocked properly. Thank you! ... View more