DNS Snooping on MX84 not working for one rule but ok on another

[Dunky]

This is in an MX84 running 15.44

I have an issue related to permitting traffic through the MX based on the L3 rule dst being defined as a domain name.

The client points to the MX for its DNS.

This works perfectly:

L3 rule> Allow ICMPv4 src:Any dst:google.com

A ping google.com on the client works, proving that the DNS snooping is working and the traffic is matching the name in the rule dst

I have another example of using a domain name as the dst which DOES NOT work:

Allow TCP src:<client IP addr> dst: <domainname> dst_port:22

We then have a scheduled job which executes this command file:

C:\winscp\winscp.com /script=c:\winscp\scripts\getrecipe.txt /log="c:\winscp\scripts\getrecipe.log" /loglevel=0 /logsize=2*10K

Exit

The getrecipe.txt file contains the following command:

OPEN SFTP://<username>:<password>@<domainname.com> -hostkey="ssh-rsa 1024 MKA*********************WelyJtFd **********"

Which fails with an error unable to open <domainname.com>

It resolves the name ok in DNS as we see it in the clients ipconfig /displaydns – for some reason the SFTP traffic is not matching the rule that permits it out.

If I put the public IP address of the dst <domainname.com> in the dst then it works, proving the MX is not matching the name it looked up.

So why does the PING L3 rule match using the dst domainname but the SFTP does not?

Any ideas anyone as its driving me mad 🙂

[CptnCrnch]

Have you seen this doc regarding FQDN support in L3 firewall?

Which brings me to the questions that need to be asked:

1. Does MX also see your DNS request for your internal SFTP URL? It's kinda natural it's seeing a request for google.com, but how does your internal DNS setup look like? Is your MX standing "between" endpoint and its DNS resolver?

2. Have you cleared the DNS cache on your endpoint machine when testing?

[Dunky]

Hi CaptnCrnch

Thanks for taking the time to reply.

1. Does MX also see your DNS request for your internal SFTP URL? It's kinda natural it's seeing a request for google.com, but how does your internal DNS setup look like? Is your MX standing "between" endpoint and its DNS resolver?

Answer: it's an external SFTP server and the client is using the MX for DNS.

2. Have you cleared the DNS cache on your endpoint machine when testing?

Answer: Yes, flushed cache beforehand and after the SFTP failed it had cached the correct public IP Address for it.

So DNS resolves correctly for both examples, it's only the SFTP rule where the dst FQDN isn't getting matched.  If I put the IP in the dst it works.

[CptnCrnch]

The only theory I can up with is based on this  discussion:

"WinSCP does not talk to any DNS. It uses a system name resolution API."

Could you try the same with a Linux based client using "regular" scp?

[Dunky]

I'm not sure how it's resolving the FQDN then and then giving the error.

When I add the dst IP to the L3 rule it works.

Will have to do some reading up on Winscp but I'm using the exact same command and script - works if IP is added to L3 dst, does not  work if only have FQDN in L3 dst.