Meraki

jmp888

Issues with using URL's on Meraki L3 FW.
We are receiving inconsistant results when using URL entries in L3 FW rules. What we have found is the firewall rule allowing the whitelisted access is sometimes matching the traffic destinations by URL and sometimes not, resulting in the traffic being dropped by subsequent rules.
For example, accessing verifone.cloud the firewall rule listing "verifone.cloud" would match and all traffic through as expected.
Repeating the tests a short while later, the same test would fail through the destination "verifone.cloud" not matching.
As a test, we tried adding the Verifone.cloud IP address to the destination FW rules & this resolved the issue and consistently provided access.

Can you please clarify if there are any situations where using URL's will cause this type of inconsistent behavior?

thanks
John

Brash

Most likely, this is due to the way the MX implements FQDN's in L3 firewall rules.

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.

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

Essentially, the DNS lookup and response for the website must pass through the MX unencrypted for the MX to snoop it and be able to match for later traffic. If the MX does not receive a DNS lookup, it does not apply the rule.
The MX will also periodically time out the FQDN to IP mapping (I'm not sure what this timer is) so if the client has a longer cache, or simply uses the IP only, the MX may stop enforcing the rule.

PhilipDAth

Web sites often use lots of other components from other web sites. You have to allow all of these for it to work.

In Chome, hit F12, and click on the sources tab. Now load the web site. For me, this is the ist of things it loads:

You need to allow all of these for the web site to function properly.

RaphaelL

According to my testing this entry doesn't have a short TTL :

> set debug
> verifone.cloud
Serveur : one.one.one.one
Address: 1.1.1.1

------------
Got answer:
HEADER:
opcode = QUERY, id = 6, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 4, authority records = 0, additional = 0

QUESTIONS:
verifone.cloud, type = A, class = IN
ANSWERS:
-> verifone.cloud
internet address = 151.101.194.191
ttl = 14396 (3 hours 59 mins 56 secs)
-> verifone.cloud
internet address = 151.101.66.191
ttl = 14396 (3 hours 59 mins 56 secs)
-> verifone.cloud
internet address = 151.101.130.191
ttl = 14396 (3 hours 59 mins 56 secs)
-> verifone.cloud
internet address = 151.101.2.191
ttl = 14396 (3 hours 59 mins 56 secs)

However it is returning multiple IPs. Maybe the MX is only allowing the first one it sees and somehow your client is trying to access the other 3.

Best way to troubleshoot this would be to take a packet capture. Snoop the DNS query in wireshark and try to find which TCP sessions hangs.

Also some weird issue can happen when multiple clients are resolving the same entry but are getting different results.

Eg : Client A gets verifone.cloud 1.1.1.1

Client B gets verifone.cloud 2.2.2.2

If I recall correctly the MX will keep the last DNS reply. That way Client A gets blocked.

I think I made a post in 2023-2024 about a behavior like this with DNS records with low TTL.

PhilipDAth

>I think I made a post in 2023-2024 about a behavior like this with DNS records with low TTL.

I *think* the issue you had was when two different domains resolved to the same IP addresses (such as two different web sites using the same CDN, landing on the same CDN node). I think the issue is the database is keyed by IP address rather than DNS name.

You can see how this works. Packet comes into MX. It looks up IP address to find out if their is a match to a DNS entry in cache. Check firewall rules for that DNS entry.

If you didn't have a database uniquely keyed on IP address, which of the firewall rules do you match?

RaphaelL

yeah you are right. This was the conclusion of my old 2023 case :

This means that if the MX receives DNS responses for 2 different URLs that share the same IP address, the latest DNS entry will override the previous one; the previous entry will not re-populate the DNS table of the MX.