FYI, it's not related to this issue (refer to this thread for updates), but if you're still running 16.16, be aware that there's a DoS vulnerability that may disrupt AnyConnect services: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-meraki-mx-vpn-dos-vnESbgBf   It is still recommended that you update to a fixed version as soon as possible. ... View more

That documentation reflects new behavior on MX18 firmware if you want to resolve a peer via a DNS name - it will only default to that if you're putting a hostname in the remote IP field. ... View more

I'm not saying you need to set that. It is an optional value yes, but it does not default to an FQDN. ... View more

That would be the spot yes, and then make sure your remote peer is configured to use that same ID as well ... View more

This is false - those IDs are set to whatever IP address the MX is assigned, and the public IP of the peer in question respectively. ... View more

Private IPs do work, you just need to specify an Identity on each side, depending on your deployment. The issue is that the SonicWall probably isn't configured expect the MX to send its private IP as its identity, or, if it's ignoring that for whatever reason, it's sending the public IP as the ID it's expecting us to use, which the MX is not expecting, and rejecting the connection.   If you had planned on deploying the MX with a static private IP, just set that as the Local ID in Dashboard, and that should make it work behind a NAT without issue I would expect (may need to make some additional changes to your SonicWall to accommodate this as well) ... View more

A NO_PROPOSAL_CHOSEN message being received on your Sonicwall means the MX is rejecting the attempt in Phase 1.   You'll want to open a support case, as there's no more debugging that can be done using the logs on Dashboard unfortunately ... View more

FYI, if you ever have any concerns about the origin of a file, you can click on the link in the details section to obtain a SHA256 hash of the file, along with a link to any results VirusTotal may have for it.   If VT doesn't have any hits, just a general Google search for the file hash is usually enough to give you a range of results to help learn more about the file in question ... View more

Many changes in regard to 17.x are still being added to 16.x as well, so if you are still having issues, please bring it back up with Support, and try to focus on what's still specifically getting blocked, along with packet captures if, and at all possible ... View more

Hello,   Just an FYI, that NBAR, and indeed the L7 firewall as a whole,  are not related to Content Filtering in any way, including the change from our previous content filtering provider to Talos. They are two separate features that rely on entirely different methods of identifying and blocking traffic.   Please continue to work with Support on looking into this, as we've recently made some considerable changes to NBAR as of last month's 16.16.4 patch, ones large enough that demand we take fresh data sets before we can continue to evaluate this any further. ... View more

Yes, 16.16.4 introduced some changes to NBAR that showed a significant reduction in false positive rates in internal testing. If you're still having issues, please raise a new support case, as we need to look at this from a fresh perspective to see what still might be going on. ... View more

I will also chime in here and say that, historically vendors have worked around this with "NAT fixups" for protocols like this that predate mass deployments of NAT (yes, TFTP is that old...) which do payload inspections, and put the appropriate NAT mappings into place based on that, but it's not something we support.   SFTP is the way to go here, if not just because it tunnels everything over SSH to avoid this problem, but to also avoid transmitting your username and password in cleartext over the internet, like you'd be doing with (T)FTP. ... View more

I know nobody likes to hear "soon™" as an answer, but I can say that I'm aware of some positive developments regarding this. ... View more

I've been trying to advocate for the need for something similar to Fail2Ban to provide more peace of mind for our customers using AnyConnect, given that TCP 443 is indeed such a common target of automatic probes on the internet. If this is a feature request you'd like to see, please submit it through the official channels on Dashboard, as that's the sort of thing we'd need for it to get more traction/consideration in terms of dev roadmaps. ... View more

Hey folks, just to close my loop on this. A few people have sent me case numbers in which our Support team tried to make some behind the scenes changes to work around this, and after digging through some data on our end, I've confirmed conclusively that it does not work. I will be sending out an internal PSA to them regarding this, but please reference this if you have a case going and they try to change things in a similar fashion - they'll know who I am, and can follow up with me internally if they have any questions. ... View more

I'd be curious to know what they said when you shared those results with them, because, at a glance at least, we are responding as we should be. ... View more

@Dunky wrote: I will PM you Alex. I am noticing that traffic to Azure is also getting blocked by this:   What we need is a way of having ALLOW rules, and specifying src and dst. And why is "Statisitcal Peer-to-Peer" not even in the dropdown??   I wish I had an answer I could give you in that regard, but it's not my place to comment on design decisions publicly. I will say that that category is aggregated as part of the Encrypted Peer to Peer categories, so anything that tries to inspect encrypted traffic will include it. Since we have no way to inspect encrypted application payloads, NBAR tries to use heuristics instead, although unfortunately the documentation is rather lacking it what it does: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_nbar/prot_lib/config_library/pp5600/nbar-prot-pack5600/s.html#wp1488575851 ... View more

It sounds like we're dealing with two separate issues here then.   Regarding the /127 issue, it sounds to me like they're claiming they're sending us a neighbor solicit - how you do the L2 to L3 mapping process in IPv6 that was performed by ARP in IPv4 -  and we're not responding, but we'd need more clarification on that, and a .pcap would also be highly recommended if you haven't taken one already, since we'll want to be able to see what's going on on the wire here. ... View more

How is the /48 being given to you? I ask because it must be advertised via DHCPv6-PD for us to be able to use it. ... View more

If you have a case number, may I take a look? What's being described here is raising some significant concerns that I want to take a deeper look into ... View more

100% agreed; if they've found a possible DoS vector, I want to ensure this gets the attention it deserves. ... View more

We take all possible DoS vectors seriously, so if you're still running into issues with this, please post your case number, and I'll try to follow up internally. ... View more

Another thing to bear in mind is that any potential bugs you may encounter on the AnyConnect Client itself may require TAC involvement to resolve that Meraki Support cannot provide, and licensing is required to be able to contact them. ... View more

This is the correct answer - Meraki Support can assist with some simple configuration questions for policies as they relate to the MX implementation, but deeper functionality on the AnyConnect client itself should be directed towards their TAC team instead. ... View more

Support team forwarded a bug about that this morning - we're looking to get answers ourselves on why it's not visible yet. ... View more