I see, so there isn't a way to have it load balance to a range of hostnames. That's the detail I was missing here. ... View more

Apologies for being obtuse here, but you wouldn't be able to purchase a SAN cert for Azure to use that contains the DDNs names of each MX? I.e. CN=vpn.companyname.com   SAN DNS:mxddns1, DNS:mxddns2, ... DNS:mxddnsN ... View more

If your clients are connecting to the Azure manager, and then being redirected to an MX, it sounds to me like they're getting a warning that the name on the initial cert doesn't match that of where they're ultimately getting redirected to. If that's true, have you considered doing something like creating a cert with an SAN that covers all of the devices you're load-balancing to? https://support.dnsimple.com/articles/what-is-ssl-san/#san-restrictions Depending on growth and scale here, it might be feasible. ... View more

What I'm not clear on is *why* dynamic certs won't work - is there anything you can do to elaborate on why? ... View more

@CiscoAnyconnect wrote: I understand but using profile doesn't help my scenario.  Since I've four MXs on four different countries with users  who are traveling a lot ,I am using Azure traffic manager(DNS load balance) to select  the nearest MX.   Dynamic cert doesn't work with my load balance name and users get trust warning message which is not a good sign for them.   I've also created different profiles with AnyConnect profile editor and tried to enable OGC but it doesn't work as it. It just select the first VPN in the list.   That's why I am thinking about custom certificates. If you choose to maintain the Azure DNS load balancing, I'd also be curious to learn more details about the Dynamic cert trust issues you're having - there may be solutions there we can pursue. ... View more

I cannot comment on feature developments in that regard right now unfortunately. ... View more

@PhilipDAth wrote: I'm kinda thinking only statistical models with an accuracy of at least 99.9% should be considered when it comes to blocking (as opposed to just monitoring).   Even at 99.9% accuracy, 1 in a thousand applications will be misclassified and incorrectly blocked.   The NBAR team really needs to also publish the confidence level for these models.  Does "best effort" mean the machine learning model was 68% confident, 95% confident, what? This is great feedback - I will bring definitely bring this up and see what additional context we can get. ... View more

The above post from @Isack2230  is correct - after some discussions with the folks who maintain the NBAR protocol packs, we got some clarification from them that the "statistical" rules are all considered "best-effort" on their part. Per some requests, the protocol pack documentation has been updated to ensure it's more clear these rules may not be as accurate as others: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_nbar/prot_lib/config_library/nbar2-protocols/nbar2-protocols/s.html#wp2346607100   For now, because of the continued issues we've seen reported with its accuracy and false positive rate, the rule has been disabled on Dashboard, and should no longer be configured or configurable.   Side note: it remains to be seen if complaints come up with any of the other "statistical" rules in the protocol pack, since they're all similarly flagged as potentially being inaccurate in the PPACK documentation. We aren't currently entertaining ideas to disable any other rules, but we'll be keeping an eye on complaints and case data that might prompt us to reconsider this position in the future. ... View more

I also agree with Phil here, and want to give a bit more technical context on this response.   A DDoS falls under the broader umbrella of what's known as a resource exhaustion attack: https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-015_Denial_of_Service   While I've seen varying descriptions, in general, any resource can fall under such an Umbrella, including network bandwidth. If someone's saturating your uplink with garbage downlink traffic, there's very little mitigating it on your network perimeter would really accomplish anyway. In a more traditional sense, we can't mitigate against a DDoS consuming CPU or memory either; processing that many inbound packets through our IPS and inbound firewall is always going to consume both. ... View more

Just to give fair warning, in its current form,  it's a *very* limited support feature, and it's far from being something Meraki Support can recommend using. ... View more

The only way it might be possible is if the app does any sort of separate peer-to-peer communications for file sharing, or  establishes a session with a distinct subdomain for it, but I've never used the app, so I have no clue on either. ... View more

SFTP is all tunneled over SSH, which removes the need for such NAT hacks. Past experience has dictated that any sort of NAT considerations for FTP aren't likely to be implemented given that FTP is a cleartext protocol that transmits usernames and passwords unprotected.   As for the the firewall rules, "implicit" implies that it's an unspecified behavior, which is not the case. Yes, there's a default allow rule, but it's very much explicit. ... View more

In this case, you have two options, depending on the nature of your setup: Configure the non-Meraki device to expect the private IP address of your primary uplink on the MX as the presented ID Configure the peering on Dashboard so that the LocalID of the MX is whatever public IP its traffic is getting NAT'd to ... View more

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