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:

  1. Let us know on which platform you are using DNSWatch.
  2. Let us know what your use case is in a sentence or two. i.e. “DNS protection for mobile PC’s”
  3. 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

Comments

    1. 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.

    2. 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.

  • Andrew_KraslavskyAndrew_Kraslavsky WatchGuard Representative

    A couple of questions:

    • Do both of the issues only occur when DNSWatch usage enforcement is enabled?
    • How is use of UDP port 53 as the data channel for SSLVPN client connections being prevented? I.e. is configuration of UDP port 53 for SSLVPN server on the Firebox allowed but clients are unable to successfully connect if DNSWatch is enabled on the Firebox?

    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:

    • At first, DNSWatch was enabled. When DNSWatch is enabled and listening on the Trusted interface that you are using, it will spawn a DNS forwarder on port 53.
    • After this, it seems that you configured the SSL VPN to use port 53. However, since the Firebox is already listening on TCP and UDP 53 for DNS traffic as part of DNSWatch, the SSL VPN is unable to bring up the necessary virtual interface tun0 to listen on port 53.
    • After disabling DNSWatch only, the SSL VPN processes do not get restarted, as there was no SSL VPN configuration change. After changing the SSL VPN configuration, tun0 comes up and the VPN works normally.

    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.

    • If I configure SSL VPN to use TCP 53 first, save the configuration, and then enable DNSWatch and save the configuration again, dns-forwarding and dnsmasq will have problems coming up and the SSL VPN does not connect on port 53. If I free up the conflicting ports on the Firebox, the components work as expected.

    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.

  • Andrew_KraslavskyAndrew_Kraslavsky WatchGuard Representative

    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?

  • I personally can’t get to heavy into DNS watch since it’s the only thing not configured in the WG cloud.

    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.

Sign In to comment.