Thank you - I will be doing some internal following-up to see if we need to file a bug report about this, because I'm not sure where that errant NBAR classifier is coming from if it's not defined under the previously referenced protocol pack documentation. ... View more

Following-up on this; if clients still see such restrictions after turning this off, make sure you flush DNS on said clients, as this restriction works by transparently modifying DNS queries, and a cached result means it will continue to be enforced even after the feature is disabled. ... View more

If you have a case number to provide, I would like to do some internal following-up on this if possible ... View more

For context, we use Cisco protocol packs, so no customized IDs ... View more

You wouldn't use a port forward for this anyway - if an incoming TCP packet comes in on TCP 443, there's no mechanism that would allow us to determine how to forward it on to the LAN if there were multiple IPs specified. The case you're talking about seems like what the existing 1:1 NAT functionality already covers. ... View more

Unfortunately we don't have a way to stop it alerting on that, since the entire process just checks for multiple ARP responses for the same IP coming from different MACs. You'd need some way to have at least one of those ARP responses stop reaching the MX (or getting generated) ... View more

FWIW, there have been no significant changes to the IPsec process between 15 and 16, so there's not likely much else anyone will be able to provide without some evidence as to what was going on, and a Support case is needed for that. ... View more

15.x included a change to a new IPsec daemon that enforces checks on it where previously our old one was bugged, and didn't. It's not mandatory that a value be populated on Dashboard if the default is what the peer presents when we key the IKE SA. ... View more

If the remote ID field is left blank, we default to assuming the identifier of whom we're speaking to is their public IP - this should only be necessary in cases where the peer is behind a NAT and doesn't have that public IP specified as an identifier. ... View more

Usage is a rolling average of the load on the CPU core(s) that our packet forwarding engine runs on. 100% on its own isn't necessarily an issue, unless you're noticing concerning amounts of packet queuing or loss. ... View more

If IKEv1 is working and IKEv2 isn't, you may be running into traffic selector issues: https://documentation.meraki.com/MX/Site-to-site_VPN/IKEv1_and_IKEv2_for_non-Meraki_VPN_Peers_Compared ... View more

Much though I would like to, it's not my place to comment on this unfortunately. ... View more

I'm curious, why were you trying to use IKEv1 instead of IKEv2? ... View more

Interesting that you bring up it breaking Client VPN, because that was not part of our scope on the issue I described (although you're correct that they share the same internal process). ... View more

Do you happen to be using VRRP? If so, an issue was reported last week involving the IPsec process not functioning properly after a failover, and sometimes on startup as well.   If so, we already have a patch for it in internal testing, but in the mean time, the scope of the issue has been confirmed to not impact 16.11 if you still want to use any functionality in the new release track. ... View more

Agreed, the best solution in this case is WSUS, or some other automated management solution to help manage when updates are rolled out to clients: https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus ... View more

Yes, talks have been in the works for a while about this. Trust me, Support wants this as much as anyone, but we also need to make sure it's done right. ... View more

Hey Kevin, A support case is your best course of action here; we have access to the raw logs from the client VPN process (also strongSwan incidentally enough) and that'll give us a more detailed indication of what proposals we saw from your client, and why they were rejected. ... View more

This is correct - between MX14 and MX15, we changed to a new IKE/IPsec management process, which lead to the stricter requirements ... View more

Since our content filtering is currently provided by a third-party, sometimes definitions may change without our knowledge or control. As others have pointed out, as of 17.x firmware, definitions will be provided more internally from TALOS.   In the mean time, if it's not possible to add those domains to your permit lists in content filtering, and you have reason to suspect a domain was misclassified, please open up a Support case. We have a contact form with Brightcloud we can use to report misclassifications to them, and get those domains corrected. ... View more

We've had some rumblings of Windows changing their transform sets off what we default to - a Support case can help you diagnose it further, and update it accordingly without needing to roll back any security patches on the client side. ... View more

FYI, Z1's cannot run firmware never than 14.x, so if you're having a problem on a Z1, it's not related to firmware most likely ... View more

If you're having issues, I would contact support and tell them you suspect it's an ID issue - there is logging we have access to when the tunnel is built that will determine if the root cause of this is an ID mismatch, and it should tell us what AWS is trying to present that's incorrect if so. ... View more

There's only three things it can be:   An FQDN you've set on that end A User FQDN (e.g. you@example.fake) A public or private IP Which one it needs depends wholly on your setup. If you haven't explicitly set 1 or 2 on the AWS side somewhere, then you'd use 3, but that should only be needed if the actual endpoint you're connecting to is behind a NAT. ... View more