A Message from Product Management
Your voice matters!
WatchGuard’s DNSWatch product line is actively expanding support to include client devices in 2019. We have heard from you during the development of this solution and we want to continue that feedback as we drive the roadmap. Today, you can use DNSWatch on the Firebox, but with the addition of the client-side protection you will be able to roll out this same protection to all your users on the go!
We want to make sure that we are getting your important feedback and suggestions to the right teams inside WatchGuard so please help us out with a few simple suggestions to streamline your feature requests:
- Let us know on which platform you are using DNSWatch.
- Let us know what your use case is in a sentence or two. i.e. “DNS protection for mobile PC’s”
- Tell us what you think we could do to make the product even better and what benefit you feel it would have. i.e. “Please add feature X so that we save time in initial setup and deployment.”
Sincerely,
The DNSWatch Team at WatchGuard
0
Sign In to comment.
Comments
Current implementation of DNSWatch prevents one using UDP port 53 for SSLVPN access. I would like to use DNSWatch and use UDP port 53 for SSLVPN access.
I would like to have local DNS firewall policies be used prior to DNSWatch forwarding DNS packets to the cloud. The last time that I tried this, I could not get my DNS policies to work even though they were above the "Any From Firebox" policy.
A couple of questions:
Thanks!
My post disappeared when editing it - lovely.
Trying it again.
Yes, usage enforcement was enabled.
These issues came up in the V12.2.1 Beta.
See the responses below from the beta team.
Neither provides a desired solution for me.
SSLVPN using port 53 will not connect
Aug 31, 2018 @ 2:02 PM #6
Hello Bruce,
Thank you for providing the additional information. Here's what I noticed is happening in your Firebox for this issue:
In your case, if you leave DNSWatch and any other DNS Forwarding disabled on the Firebox and configure SSL VPN to use port 53, there should be no further issues connecting to the SSL VPN on port 53.
The reverse may also cause issues in this case.
In this case, I would call the behavior expected yet somewhat concerning. I reviewed the documentation where the recommendation to use TCP or UDP 53 is made, and will request an update to the documentation as a result of this issue. Also, I will continue to investigate whether any enhancement could be made in the Firebox when this occurs.
Thank you,
Matthew Terry
QA Engineering, WatchGuard Technologies
DNSWatch: Add Source IP exception list by Jean-Pierre Schwickerath
Sep 7, 2018 @ 12:59 AM
Hi Bruce
What you can do is disable the DNSwatch enforcement, create a DNS-policy with sources (from) that you want to have protected and in the to-field, you put a DNAT to the DNSwatch servers. For the workstations that you don't want to have protected, you just add a dns-policy in front ot it that allows access to you real external dns servers.
Thank you for providing the history.
Glad to know that Matthew is already on the case!
For the first item, I see that the associated internal ticket refers to modifying the UI to let the user know port 53 cannot be used for SSLVPN when DNS Forwarding is enabled or DNSWatch is enabled with usage enforcement turned on.
However, I think there may be a way to have the forwarder avoid listening on external interfaces so I added a note to the ticket suggesting that be considered.
Regarding the second issue that relates to policy for DNS traffic, I have recommended this be addressed via some refactoring of the DNSWatch and DNS Forwarding implementations.
This work must of course be prioritized by the Product Owners against all the other tasks already in the queue.
I realise that DNSWatchGO is still in beta.. I am very impressed by this concept and I would really like to see it expanded to tablets and mobile phones. I see it as an expansion of the fantastic old Mobile Security product, which itself was hugely under-rated by others to the point where it was left neglected by WatchGuard. I guess the Kaspersky drama in the US did not help the product either.
Adrian from Australia
It would be wonderful if DNS policies were active (executed) prior to DNSWatch forwarding - this would address my next 2 issues.
With DNSWatch enabled, one no longer can see in Traffic Monitor what DNS queries are being generated by what IP addr, as one can with a DNS proxy.
I would like the ability to log the DNS queries on an interface by interface basis.
One can't apply or not apply DNSWatch to selected IP addrs on an interface/VLAN.
I would like this ability because I want to deny certain DNS queries for certain devices, and the only way to do this is to set up specific DNS proxy policies. I should not need to create extra VLANs to accomplish this.
If the suggested solution by Jean-Pierre Schwickerath (above) to not use DNSWatch directly is what WG recommends, then this should be added to the docs in the DNSWatch section.
And, how does one "in the to-field, you put a DNAT to the DNSWatch servers" ???
As indicated by my prior post, one can no longer use UDP port 53 for SSLVPN access, which used to be recommended by WG in the docs.
Incoming access by UDP port 53 should not be prevented by DNSWatch.
For internal SSLVPN access via UDP port 53, XTM should be able to check if SSLVPN is using UDP port 53, and if so, it should be able to determine if this is a DNS query or a SSLVPN DNS access packet.
@xxup We definitely plan to support iOS and Android in future releases. Our first focus is on Windows and then ChromeOS. We are then looking to prioritize mobile and MacOS. Would Mobile be more important to you than MacOS?
@Bruce_Briggs I've reached out to @Andrew_Kraslavsky on the side to make sure we dig into this behavior. Hopefully we can get a response back to you shortly.
We use Windows and Android, which I believe are the market leaders in terms of sales volumes. Our only Mac (permanent loan from one of our customers) is used to participate in Beta testing. So my preference would be to see an Android development, but this needs to be supported by a genuine commitment to keep the product up to date with new Android versions.
Adrian from Australia
I too would love to see DNSWatchGo work on both Apple IOS and Android devices. I have a customer that is using a different solution for auditing mobile device use and it is increasingly expensive. They would move off the audit (manual process) to the DNSWatchGo model quickly especially with the power that DNSWatch already has shown them.
Add support for Linux as well.
Please add a method to cli deploy directly into a client group. This would cut our deployment time when rolling out with RMM tools.
@Ben_Oster or anyone else from WG:
Any status on my nearly 2 year old complaints?
Once it’s moved there, with the bugs that Bruce mentions fixed, we will be able to take a more serious look at DNS watch as a service.
Supposedly WG will be rearchitecting the DNS forwarding feature upon which DNSWatch runs, which would allow the actual use of DNS proxies when that happens.
I was told that this would be in a major release - such as V13, not a "dot" release, such as 12.8.