Meraki MX Firewall with FQDN

[Pugmiester]

Hi all,

Can someone help me wrap my head around this please?

We're looking to implement firewall rule that would permit traffic to specific destinations, while continuing to block everything else. The challenge is the destinations are cloud services so tend to contain many changing IP addresses.

Looking of the details in the document below, it suggests it's possible, but only if the MX sees the DNS request to match it up with the client connection.

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings

What's not clear is if that DNS request must come from the client itself, rather than from an onsite DNS server that the client is talking to.

Am I right in thinking this only works if the client machine is making the request to, for example Google DNS 8.8.8.8., so that the MX sees those requests and can match them directly back to the client IP then asking to get to sitexyz.com?

[DarrenOC · Accepted solution]

HI @Pugmiester 

I believe your understanding to be correct.  The MX must see the clients DNS request and the DNS servers response.

[Pugmiester]

That's what I thought. I was kinda hoping I was wrong but, back to the drawing board.

[PhilipDAth]

>Looking of the details in the document below, it suggests it's possible, but only if the MX sees the DNS request to match it up with the client connection.

The DNS request can be either inter-vlan or go out to the Internet or out AutoVPN to another site.  The DNS request populates the DNS cache.  The FQDN firewall rule then uses this DNS cache.

Consequently, it does not matter who made that DNS request or which DNS server it was sent to.

You do need to be careful with short-lived DNS results or queries that always return a different result with a short TTL.  For example, from memory, Facebook uses a TTL with 60s.  So you can get a case where client "x" does a lookup.  Client "y" does a lookup a short time later but gets a different result.  The firewall rule ends up using only one of these results, so one client works and the other does not.

Something like that.  Explanation not exactly right.  But jist is.

On the whole, it works great with most cloud providers using rotating sets of IPs, but not all of them (only a small percentage that don't work well).

[brianpmcp]

Any Idea if this is compatible with using Umbrella SIG with Anyconnect? If the DNS requests are encrypted would that hide the DNS request from the MX breaking the FQDN firewall rule?

[PhilipDAth]

That choice is really up to you.  You configure whether Umbrella SIG encrypts its DNS queries while connected to your VPN headend.

[CptnCrnch]

As @PhilipDAth already mentioned, this comes down to an architectural design. For my customers, I'd recommend to let Anyconnect disable itself when the endpoint is located within a network protected by an MX and let it do its job. MX is now able to see the request and act accordingly even before it hits SIG over the VPN tunnel.

[brianpmcp]

Thanks for the quick replies. In this scenario I need the anyconnect Umbrella roaming module to map AD users for SWG policies so can't disable it. I don't have a site to site VPN to Umbrella. Anyconnect module encrypts the DNS queries to Umbrella from what i've read.

[PhilipDAth]

You could deploy the Umbrella virtual appliances on-premise if you would like to keep the same functionality.

But it doesn't sound like you really have an issue.  You can just use Umbrella for enforcement and tracking of the users, rather than the MX.