FQDN not resolving in MX firewall rules.

[AnotherRon]

Has anyone experience an issue with a FQDN in a firewall rule not resolving?

I have the following example (addresses and FQDN have been anonymized):

Policy = Allow

Rule Description = Payroll

Protocol = TCP

Source = 192.168.20.0/24

Source port = Any

Destination = online.payroll.com

Destination port = 491

This rule fails, and syslog records the denied session attempts, but if I add the IP address for the FQDN to the destination in the rule it works.

[Mloraditch]

Does the FQDN always resolve the same?

There are limits to FQDN support detailed here: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#FQDN_Support

It's somewhat limited and not as well built as other vendors. The MX only learns FQDNs via client requests and if those requests aren't in the clear (i.e DoH) or previously cached it won't see them. And if the record in question provides round-robin responses or is otherwise dynamic, it may not properly track the FQDN.

[AnotherRon]

Thanks, for the response. As far as I can see the FQDN complies with all the requirements in the link you provided. Access to the DNS server is not intra-vlan, and the powershell script "test-netconnection online.imspayroll.co.nz -port 491" also fails.

[Mloraditch]

I suggest working with support at this point. You could be encountering a bug.

[ww]

Could you make a packet capture on the mx lan. And then run that script.

Look if the host does a udp dns request

[RaphaelL]

I was going to comment this , even if it sounds stupid a MX cannot snoop a TCP DNS request. It must be UDP unencrypted. 

[AnotherRon]

Thanks, packet capture isn't that easy because there's a 12 hour time difference between me in London, and the problem location in New Zealand. I've added the FQDN IP address into the rule as a workaround and I won't be able to remove that until the month end payroll runs are done. I think I'll have to open a case with Meraki.

[ww]

You dont need to change the config or rule. You can just make the capture (on mx lan or client device) and run the powershell script (or even better from a real client device ). Its just to verify the powershell script using unencryted udp for dns lookup.

Ofc also create a case, they can assist you way better looking into device and config

[alemabrahao]

Is this URL an address that responds externally or only internally? If it should respond externally, it makes sense that it wouldn't work, since I just ran a test and this URL doesn't exist.

You can also run a test directly from the MX, on the appliance status page in tools.

[AnotherRon]

Thanks for the response

The address was anonymized but there's no real need for that. It's actual FQDN is online.imspayroll.co.nz and it resolves correctly to 13.210.191.42 in the MX status page in tools.

[ChrisJ2]

Hi,
there are a few caveats for using FQDN in L3 firewall rules:

• The MX must see the client's DNS request and the server's response in order to learn the proper IP mapping.
• The communication between the client and DNS server cannot be intra-VLAN .
• Additionally, in some cases the 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 DNS entry in a host file. The MX will not be able to block communications to the web resource in these cases.
• You should configure a L3 allow rule for DNS traffic, eg:

         this rule should be placed above the rule containing the FQDN.

hope this helps!