Hi Bucket, it isn't that NAT stops working, it's that the default route installed to the appliance creates an asymmetric route.   For sites with resources that need to be accessible from the public internet, you need to either create a VPN exclusion rule to break traffic out of the VPN tunnel, or deploy the appliance as a hub to prevent the default route from being propagated. ... View more

Hi Bucket,   With the addition of Secure Connect there are three types of firewall rules.   MX > Firewall LAN to WAN traffic LAN to LAN traffic MX > Site-to-site VPN > S2S outbound FW LAN to VPN traffic SC > Cloud Firewall (CDFW) Any traffic sent to Secure Connect > Any   Which one of these rules is enforced depends on where traffic is sourced and destined to.   For example, if I'm a user on subnet-a trying to communicate with subnet-b, and I have rules on both the Meraki MX firewall and Secure Connect firewall, my traffic will hit the Meraki MX first, where I have a rule in place to drop the traffic.   Alternatively, if you have a remote access user connecting to the VPNaaS, and have a rule setup to block traffic to both subnet-a & subnet-b, and the user attempts to communicate with hosts on those subnets, they'll be blocked by the Secure Connect firewall.    I've attached an image which expands on this idea to include internet-bound traffic too. Please note, in reality, Meraki MXs configured as a spoke connecting to Secure Connect will have a default route installed in the route table, so you'd need a VPN exclusion rule for attacker.com for it to break out to the WAN and have the Meraki > Firewall policy be applied. I've only done this scenario for presentation purposes.     Blocking traffic closer to the source is recommended, but some organizations may choose to consolidate their rules in Secure Connect for easier management. There are roadmap items coming soon which will allow IT administrators to block traffic closer to the source without the complexity I've outlined above.   To address your questions directly:   1. Site-to-site outbound firewall rules are still applied. If your Meraki MX is a spoke, a default route is installed in the route table. Unless there is a more specific route in the route table, all traffic will be forwarded to Secure Connect.   2. If the traffic is being sourced from behind the MX, then policies on the MX are evaluated first before being forwarded anywhere else, i.e. Secure Connect where you may have additional policies   3. Regardless of whether the spokes are communicating through an MX/vMX or Secure Connect, the Site-to-site outbound firewall rules are evaluated first. For the Secure Connect Cloud Firewall policies to be applied, the traffic must relay through Secure Connect.   Hopefully this helps. ... View more

Within the scope of VPN exclusion rules, DNS only matches against queries sent over UDP 53 - https://documentation.meraki.com/MX/Site-to-site_VPN/VPN_Full-Tunnel_Exclusion_(Application_and_IP%2F%2FURL_Based_Local_Internet_Breakout)#Configuring_VPN_Exclusion_Rules_(DNS_Hostname)   The Arctic Wolf whitepaper only seems to state TCP 443 so I'm guessing/assuming they're doing DNS over HTTPS (DoH).   Try changing the individual rules so the protocol is TCP, and port number is 443. ... View more