Wildcard FQDN not working because STUN tunnels DNS request?

[scheuri]

Hello all

Our clients have a phone software installed which needs internet connection.

There are several firewall policies in place to allow said phone software to connect to several internet places. The producer of the phone software needs us to allow *.amazonaws.com on a UDP port range.

There are other needed wildcard fqdn used by that phone software and those seem to work (fortigate gets IP addresses for those wildcard FQDNs).

However, that one FQDN *.amazonaws.com doesn't work - no IP addresses in the fortigate DB.

Yet the phone software tries to open a connection to an AWS IP which does not succeed as the wildcard FQDN doesn't get any IP addresses.

We suspect that the STUN does "hide"/tunnel the DNS request for the AWS-FQDN requests and therefore Fortigate can't learn its IP.

Does someone have experience in this and knows how to circumvent that and make sure we can open the AWS IPs on those particular Ports?
(Using AWS as Internet Service opens up every single TCP and UDP port and is therefore way too open).

Thanks

[gfleming]

What is the DNS server the phones are using? Why would some DNS requests get hidden and others not? What is your rationale for this behaviour?

What do packet traces/captures show?

Are you sure there is a DNS lookup occuring for the AWS IP address that does not succeed? Could it be static config?

[scheuri]

Hello gfleming

The clients (laptops - no phones per se) use an internal DNS server.

Those internal DNS servers are reachable over a VPN that is established on the branch fortigate.

The reason why I think some of the DNS requests get "hidden" of sorts is - we see DNS requests for the initial website top open the web based application, but then the documentation claims they need to establish a connection to *.amazonaws.com to go on further (audio).

However, we don't see any DNS requests that match this FQDN (so we can't really test them individually) - but we see attempted connections to IP addresses that belong to AWS. Those connections don't work as Fortigate has no IP to the wildcard-FQDN (they work once we add the indiviual IP to the firewall policy, however, the IP can change anytime).

So we suspect that something is either not working right in terms of population the wildcard FQDN or the documentation of the phone manufacturer is not entirely correct.

Using the "internet service" for Amazon AWS does open all TCP and UDP ports and we are very reluctant to use that one (unless I am missing an option to use the internet service and limit the ports for the firewall policy using the internet service)

Best regards

Stefan

[gfleming · Accepted solution]

You should see all DNS requests being made if there is a DNS request being made. If the software is programmed to use a different DNS server you should still see those DNS requests. Use packet captures if you have to. If I were you I would investigate a bit more because I like to know exactly how my installed software is behaving. I also like to know when something is bypassing my internal DNS. 

But yes to answer your other question you can customize ISDB fairly easily. Here's documentation: 

https://docs.fortinet.com/document/fortigate/7.2.3/administration-guide/819577/internet-service-cust...

[scheuri]

Thank you very much for the information about the ISDB, much appreciated.

As for the client - we will investigate some more. The web based application uses several wildcard domains and those are working (meaning: they are getting populated with IP addresses on fortigate). So there is no reason at the moment to believe, that for *.amazonaws.com it shouldn't work.

We will try to capture more data - its not unlikely that the application doesn't behave as it should like :)

Thanks for your help, much appreciated

[gfleming]

You're very welcome. In my opinion it likely could be a hard-coded IP address. But again, you should be able to get the full picture by running a packet capture and see if there's a DNS lookup for that IP or a some kind of tunneling taking place—from what I know about STUN it would not tunnel DNS requests, however.