Layer 3 Firewall FQDN issues

[TimP]

Hey all, 

This has probably been asked before but my search hasn't given me what I need.

I've got a network, and I'm going to simplify to the relevant parts but ask questions if needed:

I have an MX84 and an MR33. DNS is routed via Umbrella.

I have many VLANs/subnets that route via the MX, so I can't blanket this restriction with a L7 or Content filter (well, from my research anyway)

I've got Android based Honeywell barcode readers that need to access specific URLs for Dynamics 365 mobile warehouse app:

*.microsoft.com

*.microsoftonline.com

login.windows.net

*.appcenter.ms

*.ces.microsoftcloud.com

*.onyx.azure.net

play.google.com

itunes.apple.com

*.cdn-apple.com

*.networking.apple

login.microsoftonline.com

login.microsoft.com

sts.windows.net

login.partner.microsoftonline.cn

login.chinacloudapi.cn

login.microsoftonline.us

login-us.microsoftonline.com

*.applicationinsights.azure.com

*.applicationinsights.azure.us

*.applicationinsights.azure.cn

*.gstatic.com

*.googleapis.com

CLIENTPRODURL.operations.dynamics.com

I've also allowed TCP/UDP 53 out for all for DNS

I've done a few audits using Umbrella reporting - compared the URLs, thats why gstatic and googleapis is in my list. 

I've got a test lab set up where DHCP is the Meraki and DNS is the Meraki

My reference article for these URLs is: Install the Warehouse Management mobile app - Supply Chain Management | Dynamics 365 | Microsoft Lea...

The problem is, despite this the app isn't working

I guess there's a few points to my question

1) Has anyone successfully limited the D365 Warehouse Management Mobile app using L3 rules?

2) What's the proper formatting for wildcard rules using FQDN. Presently I have them as policy objects without wildcards (such as microsoft.com for anything microsoft.com related)

3) Any suggestion of Android based applications for troubleshooting network connectivity issues?

[alemabrahao]

Have you tried doing a packet capture on the MX to see what is being blocked?

What about the umbrella?

[TimP]

In prod, yeah but it was too noisy - I've been focusing on Umbrella and forgot about this - Wireshark isn't a strong point of mine anyway but I'll sus it out

[RaphaelL]

Wireshark will be the way to go. 

5 easy steps.

1-Look for TCP SYN retransmission. (tcp.flags.syn == 1 and tcp.analysis.retransmission) && (tcp.flags.ack == 0)

2-Note the destination IPs

3-Search any DNS replies with those IPs.  dns.a == xx.xx.xx.xx

4- Find the DNS queries tied to the DNS replies from step #3.

5- Add those Domains ( from the DNS queries from step #4 ) to your rulebase.

[TimP]

Thanks, I'll give it a go. I've got a restricted, and an unrestricted capture available. Thank you for the clear steps - I found some articles but that was only for HTTP traffic, not HTTPs

[alemabrahao]

https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering#Using_...

[TimP]

If I'm to understand this is for Content Filtering, not L3 rules? I've seen conflicting information around FQDNs in L3 rules.

With content filtering, doesn't that apply to everything that passes the MX? I only want to limit the URLs to a specific subnet which is why I've been going down L3 rules

[alemabrahao]

You need to allow it on content filtering.

[TimP]

even if content filtering is disabled?

I'll add my list in to the Allow list now to test

[alemabrahao · Accepted solution]

FQDN-based L3 firewall rules are implemented based on snooping DNS traffic. When a client device attempts to access a web resource, the MX will track the DNS requests and response to learn the IP of the web resource returned to the client device. 

There are several important considerations for utilizing and testing this configuration:

The MX must see a client DNS request and the server's response to learn the proper IP mapping. The DNS request doesn't need to be from a specific client, the MX will map the FQDN based on the DNS response, regardless of which client made the DNS Request. The communication between the client and DNS server cannot be intra-VLAN (this DNS traffic is not snooped).

In some cases, a client device may already have IP information about the web resource it is attempting to access. This could be due to the client having cached a previous DNS response, or a local statically configured DNS entry on the device. The MX may not be able to properly block or allow communications to the web resource in these cases if the client devices do not generate a DNS request for the MX to inspect.

FQDN rules imply a wildcard when no subdomain is used by prepending a * to the domain.tld. This wildcard is not shown on the Dashboard but is visible in syslog messages if syslog is configured for a network. For example, a rule to permit "yahoo.com" would permit any subdomain under yahoo.com such as mail.yahoo.com. Permitting "mail.yahoo.com" in the rule would only permit mail.yahoo.com and not the TLD or other subdomain of yahoo.com. 

MX will not be able to snoop TCP-based or encrypted DNS traffic. 

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

[TimP]

OK So you are nudging me in the sections I found and pretty sure I won't be able to achieve what I want:

I think the key element you've confirmed here was the no-intra VLAN snooping etc - while I was in Umbrella checking the request logs I started diving into policies but I don't seem to be able to create a broad policy on an internal subnet (haven't read any guides on this yet, literally just found it).

You've helped me confirm that it won't be available. I'm pretty sure I did find the above back in February when I was last looking at this ticket but it got deprioritised for a while.

I'm going to mark the above as the solution and close this one off, thank you so very much for the speedy replies, you're worth the kudos you've been getting!

[ChristophW]

Does the DNS-Snooping work when in the mx dhcp-server on the dns-server "proxy to uplink dns" ?
I have a problem only blocking pings to one site. Nothing special...

[dperusich]

Sorry to reopen this thread, but am I the only person that thinks "DNS snooping" is the most nonsensical way to resolve hostnames to IP Addresses? The resolver libraries and related functions have been part of UNIX systems for like 40 years, which provide a reliable way to resolve hostnames, that don't require snooping traffic. It is very common in large networks that the DNS traffic between the client and DNS server is intra-VLAN and would never been snoopable by the MX.

I would strongly encourage everyone affected by this unreliable FQDN resolution implementation to...

1. Open a support case regarding this issue
2. Use the "Give your feedback" asking for a reliable FQDN implementation
3. Contact and speak to your Cisco Account Manager regarding this unreliable FQDN resolution implementation.

[rsafadi911]

agree , it really doesn't make much sense , please report this to your meraki reps so they fix in future releases. in the meantime , i will try to allow 53 / tcp for dns requests. before the deny all / allowed fqdns for layer3 rule in a group policy, to see if that helps.