I'm having trouble connecting to the Any Desk server when DPI-SSL is active. Similar services like Teamviewer work. If DPI-SSL is deactivated, a connection to Anydesk is possible. Exclude settings do not work. Does anyone have a solution?
@Ralph I can't recall having any general trouble with AnyDesk and DPI-SSL, but I remember an unconventional CN Exclusion named "AnyNet Relay" (without Quotes). Do you have this CN already excluded and still not working?
@BWC The AnyNet Relay is exclused. Also the .anydesk.com and the IP 239.255.102.18 as the default value connection (According Anydesk). In the Connection Failures there are no blocked connections that I could assign to Anydesk.
@Ralph cleanup drops are usually no problem, you should monitor the whole traffic between the endpoint and AnyNet to have a look if the exclusion really works or another CN is involved which might need to be excluded.
Anydesk uses extraord,nary ip you cannot find on the dpi-ssl list. You must analyze on the packet capture. I have seen before. I waste a lots of time for anydesk exclution😀
I looked at the packages. There are a whole range of IPs that are being tried. You could then exclude them all. But that's not a good permanent solution for me. I am currently in contact with Anydesk support. Let's see what comes from there.
In App Control I found anydesk signatures. Is that maybe a way? Does anyone have experience with this.
@Ralph when you checked with the Packet Monitor, did you had a look at the Server Hello the Anydesk Servers provided and made sure that none of these were issued by your DPI-SSL CA? I wouldn't exclude by IPs if there are to many involved. If it's SSL/TLS related the CN exclusion should work just fine.
App Control might not work as expected because you don't break up SSL/TLS to see inside the stream, somewhat of a catch 22 situation.
I've faced off this problem some times ago and after an extensive troubleshooting activities with SonicWall Techy we found that in my scenario the blocking reason was the flag "Always authenticate server for decrypted connections": disabling it, AnyDesk worked fine again.
I've also had the Any Net certificate as excluded:
Hello Ralph, I do a couple of other test on my home environment (TZ270W with DPI-SSL enable).
Firstly I have analyzed the traffic AnyDesk does to its home using packet monitor. From the attached pcap.NG file (pls rename its extension after download in .pcapng or chose to open with Wireshark) you are able to see the complete trace from my client negotiating to AnyDesk server on port 443, 80 and 6568. And you are also able to discover the issue was a Fatal Error for the TLS 1.2 negotiation related to Unknown CA.
I have tried the same solution proposed by import the two CA certificates mentioned on my firewall repository (this requests firewall to restart) and verified it: unfortunately it doesn't work anyway... same problem reported by the trace.
Thus, I've opted for a more brutal solution...
I have created an FQDN address object WAN located for *.net.anydesk.com
I create an allow rule in LAN>WAN intersection with the above fqdn object as destination
I have set off the Client DPI SSL toggle in the Security Profile of this rule
And then for me this work, allowing me not to disable DPI-SSL feature to assist partners and customers with this tool.
I am agree this is most a workaround rather than a stylish solution... I hope other guys and experts can analyze this problem deeply and find a complete solution.
Answers
@Ralph I can't recall having any general trouble with AnyDesk and DPI-SSL, but I remember an unconventional CN Exclusion named "AnyNet Relay" (without Quotes). Do you have this CN already excluded and still not working?
--Michael@BWC
@BWC The AnyNet Relay is exclused. Also the .anydesk.com and the IP 239.255.102.18 as the default value connection (According Anydesk). In the Connection Failures there are no blocked connections that I could assign to Anydesk.
@Ralph did you do a Packet-Monitor to see if the Traffic is still inspected (rewritten) by DPI-SSL?
--Michael@BWC
@BWC I monitor my traffic and found some dropped packets. Often Drop Code 737 and some 727 and 166.
@Ralph cleanup drops are usually no problem, you should monitor the whole traffic between the endpoint and AnyNet to have a look if the exclusion really works or another CN is involved which might need to be excluded.
--Michael@BWC
Hi @Ralph
Anydesk uses extraord,nary ip you cannot find on the dpi-ssl list. You must analyze on the packet capture. I have seen before. I waste a lots of time for anydesk exclution😀
Hi @BWC & @MitatOnge
Thanks for your answer.
I looked at the packages. There are a whole range of IPs that are being tried. You could then exclude them all. But that's not a good permanent solution for me. I am currently in contact with Anydesk support. Let's see what comes from there.
In App Control I found anydesk signatures. Is that maybe a way? Does anyone have experience with this.
@Ralph when you checked with the Packet Monitor, did you had a look at the Server Hello the Anydesk Servers provided and made sure that none of these were issued by your DPI-SSL CA? I wouldn't exclude by IPs if there are to many involved. If it's SSL/TLS related the CN exclusion should work just fine.
App Control might not work as expected because you don't break up SSL/TLS to see inside the stream, somewhat of a catch 22 situation.
--Michael@BWC
Hello Ralph,
I've faced off this problem some times ago and after an extensive troubleshooting activities with SonicWall Techy we found that in my scenario the blocking reason was the flag "Always authenticate server for decrypted connections": disabling it, AnyDesk worked fine again.
I've also had the Any Net certificate as excluded:
Let me know if this also fit for you.
Regards
Hi @Enzino78
I tested it with your suggestion. Unfortunately without success. ☹️
Hello Ralph, I do a couple of other test on my home environment (TZ270W with DPI-SSL enable).
Firstly I have analyzed the traffic AnyDesk does to its home using packet monitor. From the attached pcap.NG file (pls rename its extension after download in .pcapng or chose to open with Wireshark) you are able to see the complete trace from my client negotiating to AnyDesk server on port 443, 80 and 6568. And you are also able to discover the issue was a Fatal Error for the TLS 1.2 negotiation related to Unknown CA.
So, I've googled to looking for this specific issue and I've found the following thread on PAN firewall that reports the same problem:
I have tried the same solution proposed by import the two CA certificates mentioned on my firewall repository (this requests firewall to restart) and verified it: unfortunately it doesn't work anyway... same problem reported by the trace.
Thus, I've opted for a more brutal solution...
And then for me this work, allowing me not to disable DPI-SSL feature to assist partners and customers with this tool.
I am agree this is most a workaround rather than a stylish solution... I hope other guys and experts can analyze this problem deeply and find a complete solution.
Regards.
Hi @Enzino78
Thank you for your suggestion. I will test it with us.
Ralph
Hi @MitatOnge
I checked and the Anydesk connection is working now.
Thank you for your help.
Ralph
Hello Ralph,
I'm glad the problem was solved. You can narrow down the IP subnet block. You can try as 116.202.225.0/24.
Best Regards
So in the end, which solution did it for you? I have the same problem here.
@SonicPuk
you can find solution below.