We're in the process of transitioning models from 2.9 to 3 as of MX16 firmware ... View more

"Identity protection" refers to IKEv1 Main Mode; I'm not sure if Azure still allows for IKEv1, but it sounds like it might be expecting IKEv2 ... View more

https://documentation.meraki.com/MX/Site-to-site_VPN/IKEv1_and_IKEv2_for_non-Meraki_VPN_Peers_Compared#IKEv2 It's not that there can only be one subnet, it's that both sides need to be able to support building a single IPsec tunnel that encompasses each source and destination. The upside is that this scales a lot better, and is far easier to troubleshoot. The downside is, some vendors have been having to play catchup to the IKEv2 standard, and still impose the "one pair per IPsec tunnel" rule that existed in IKEv1. Last I heard, ASA was working on a new release that should resolve this, but I don't have any more info on what that looks like, or if it's out yet. ... View more

> We have used StrongSwan a lot and it's great As of MX 15, so are we, and I can confirm it's far easier to work with than what we dealt with in the past 😁 ... View more

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