AnyDesk Disconnected After 10 Minutes When Client Is Behind a WatchGuard Firewall
We've started using Anydesk to monitor a server, which means there's a lot of idle time on the connection.
When the client PC is behind a WatchGuard firewall, the connection is dropped after 10 minutes. This happens for client PCs on two disparate LANs behind different models of firewall.
When the client PC is not behind a WatchGuard firewall, i.e., is connected via a cell phone hotspot, the disconnects do not happen.
NOTE: the host machine, the one we need to monitor, is NOT behind a WatchGuard firewall
This tells me the disconnects are somehow being caused by something in the firewalls.
I've read the Anydesk notes on disconnects and implemented them but none of the proposed fixes make any difference.
The firewalls in question are a T-15 and a T35, both are Fireware 12.5.3 build 621090.
I'd appreciate any help on this,
Thank you.
Best Answers
-
The docs show that these FQDNs types should work, as long as a DNS request for them are going though the firewall:
You can also use subdomain wildcards, for example:
*.b.example.com
*.b.c.example.com
*.b.c.d.example.com
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/fqdn_about_c.htmlSince this does not seem to be working for you, consider opening a support incident on it.
You could add a DNS proxy policy From: the Anydesk client IP adddr, with Query Names -> Default set to Log, to see the DNS queries in Traffic Monitor.
5 -
In theory, "*.anydesk.com" should cover all subdomains, such as abc.net.anydesk.com and the ones you posted.
Gregg Hill
5
Answers
Anything in Traffic Monitor when this happens to help explain this?
XTM has a default timeout of 60 minutes for TCP sessions, so I would not expect this.
You could add a specific policy for outgoing access to the server public IP addr to be monitored, and if needed, you can set a custom idle timeout on it.
If your config is allowing this access out via a HTTPS or HTTP proxy, then the proxy action has a lower session timeout - the default is 10 minutes.
Set up a packet filter From the client PC or LAN to the domains and ports that AnyDesk uses.
Gregg Hill
That is indeed the key but easier said than done.
Information from Anydesk says it uses sites on *.net.anydesk.com. It does not publish a list of IP addresses or names for these sites so far I can find.
In one session, Anydesk opened connections on port 443 to relay-bc1d002c.net.anydesk.com and port 80 to relay-f93d196b.net.anydesk.com. The former connection opened on the client machine when the program started and stayed open until the program closed. The connection to the latter opened when the client machine contacted the host. After 10 minutes, it dropped and the connection to the host along with it.
This is where your idea of packet filters comes in, sort of. Luckily, both sites are in 64.31.35.0/24 (64.31.35.22 and 64.31.35.242), so I added HTTP and HTTPS packet filters with this subnet and it did the trick.
Since the names of these Anydesk machines are pretty much gibberish, I have to assume they are picked by some rule that looks like random from here. Indeed, in the next session, Anydesk used a"relay" site that's on a different subnet. So we have proof of concept but no apparent way to make something operational.
Are there any thoughts on how to actually use *.net.anydesk.com in those packet filters?
Thank you!
Addendum: I may have found a better workaround. https://hackertarget.com/find-dns-host-records/ gives a list of ALL the hosts and their IP addresses in a domain. There are 424 sites under *.net.anydesk.com. For those who might find it useful, I've got this list in the WatchGuard IP address import format and I'd be happy to share it (is there a way to upload a file here?).
I call this a better workaround rather than a solution because I'll bet Anydesk changes the relay machines' names and addresses on a regular basis for security reasons. Kind of takes us back to the question of how to put *.net.anydesk.com into policy as the destination.
You got me pointed in the right direction but with a snag, as you’ll see.
Anydesk opens at two connections to machines in net.anydesk.com. From the names, it’s clear that these machines are picked by random chance (or some algorithm), so there’s no assurance that you’ll get the same ones from one session to another. In the session I have going right now, the machines are relay.32009a5.net.anydesk.com and relay-f93d196b.net.anydesk.com. Next session one or both may be different. Also, they may use either HTTP or HTTPS, for no apparent reason.
One of these connections is between the client and Anydesk. It’s opened when the software loads on the client machine and stays open until the client software is shutdown. The other connection is opened when the client connects to the host machine. This is the session that times out when there’s no activity between the client and the host. Getting this connection running through a policy with a long time out fixes the disconnects, so you’re dead on.
Now for the snag: Anydesk does not, so far as I can find, publish a list of these machines; it says only *.net.anydesk.com and this does not, again so far as I know fit into the destination of policy.
I have found a workaround that might or might not turn out to be useful. I found a site that can pull ALL the A records for a domain, including any subdomains (https://hackertarget.com/find-dns-host-records/). At the moment, there are 424 machines under net.anydesk.com with IP addresses scattered all over the place. I pulled this list, converted it to a WatchGuard IP address import format and loaded it into HTTP and HTTPS packet filters with long timeouts. It works!! andI’d be happy to share the file if anyone wants it. (I used App Control to keep the firewall from going through this list every time a new request comes it).
The problem is that this list is probably not static. I’d bet that Anydesk changes at least some of the machine names and addresses on a regular basis, so the real solution is a way to use *.net.anydesk.com at the destination for those policies.
Any idea how, or if, this can be done?
Again, thank you for your help!
You got me pointed in the right direction but, as you’ll see, there’s a snag.
Anydesk opens two connections from the client to machines in the net.anydesk.com domain. One of which is with Anydesk and the other is with the host machine. The first one opens when the software is started on the client machine and the second opens with the client actually contacts the host. These two sessions are to machines that are selected seemingly at random. Also, the connections are either HTTP or HTTPS, also for no apparent reason.
In my current session, the machines are relay-8cc04380.net.anydesk.com and relay-f93d196b.net.anydesk.com. Next time, one or both will be different. The connection opened when the host is contacted is the one that times out when there’s no activity.
Anydesk only addresses this as requiring access to *.net.anydesk.com, which does not work in a policy destination. So far as I can find, there is no published list of either machine names or IP addresses but I was able to generate one using the web site https://hackertarget.com/find-dns-host-records/. This site can find all the A records for any domain AND all its subdomains.
There are 424 sites in net.anydesk.com. I converted the list from this web site into a WatchGuard IP address import file and loaded it into HTTP and HTTPS packet filters with long timeouts and the disconnects stopped! I used App Control to keep the firewall from having to blow through that entire list for each new request. I would be happy to share the list (or upload it here if I can).
The problem is that I doubt that this list is static. I’d bet that Anydesk changes the machine names and/or IP addresses on a regular basis for security reasons. This is the snag!
Does anyone have an idea of how to use *.net.anydesk.com as a policy destination? Can it be done at all?
I’d appreciate any idea on this and, once again, thank you for your help.
Thank you both for your suggestions.
I must have done something wrong when I first tried to add *.net.anydesk.com as the destination in the policies. I tried again today, making sure I added it an FQDN, and it worked.