Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DPI issue with AnyDesk Software

We're having an issue with anydesk beeing blocked in DPI due to invalid Certificates.

Anydesk uses own certificates, not trusted anywhere but in their software.

CN = AnyNet Root CA

CN = AnyNet Relay

Both seem to have the same fingerprint: 9e:08:d2:58:a9:02:cd:4f:e2:4a:26:b8:48:5c:43:0b:81:29:99:e3

We created a firewall rule for the users that need Anydesk, allowed HTTP/S and a custom port of Anydesk 6568

No WebFilter enabled on that FW rule, no IPS and App Control either.

Still the traffic comes to the DPI where it's blocked because of: TLS handshake fatal alert: unknown CA(48).

I don't understand why the traffic is scanned by DPI when the firewall rule has no webfiltering enabled.

I was able to install the AnyDesk Root CA to XG but not the Relay Certificate as CA which generates an error.

Certificate isn't a valid CA certificate or can't be used for signing.

This is the firewall rule 320 that hits here

and that the DPI rule

This is a packet in firewall log

2022-05-23 11:45:03Firewallmessageid="00001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" con_duration="11" fw_rule_id="320" nat_rule_id="0" policy_type="2" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="Anydesk" app_risk="3" app_technology="Client Server" app_category="Remote Access" vlan_id="" ether_type="Unknown (0x0000)" bridge_name="" bridge_display_name="" in_interface="lag0.13" in_display_interface="User" out_interface="lag0.2524" out_display_interface="lag0.2524" src_mac="68:84:7E:8D:A0:8A" dst_mac="C8:4F:86:FC:00:0D" src_ip="172.16.xxx.xxx" src_country="R1" dst_ip="138.199.36.117" dst_country="" protocol="TCP" src_port="52930" dst_port="443" packets_sent="7" packets_received="5" bytes_sent="544" bytes_received="2742" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="LAN" src_zone="LAN" dst_zone_type="WAN" dst_zone="WAN" con_direction="" con_event="Stop" con_id="754337024" virt_con_id="" hb_status="No Heartbeat" message="" appresolvedby="EAC" app_is_cloud="0"

This is a packet in DPI log:

2022-05-23 11:44:53SSL/TLS inspectionmessageid="19018" log_type="SSL" log_component="SSL" log_subtype="Error" severity="Information" user="" src_ip="172.16.xxx.xxx" dst_ip="138.199.36.117" user_group="" src_country="R1" dst_country="" src_port="52930" dst_port="443" app_name="" app_id="0" category="IPAddress" category_id="83" con_id="754337024" rule_id="8" profile_id="3" rule_name="LAN-2-WAN" profile_name="Strict compliance" bitmask="Valid" key_type="KEY_TYPE__EC" key_param="EC secp256r1" fingerprint="9e:08:d2:58:a9:02:cd:4f:e2:4a:26:b8:48:5c:43:0b:81:29:99:e3" resumed="0" cert_chain_served="TRUE" cipher_suite="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" sni="138.199.36.117" tls_version="TLS1.2" reason="TLS handshake fatal alert: unknown CA(48)." exception="" message=""

What has to be done, to get this traffic out of DPI or to make XG trust the certificates?



This thread was automatically locked due to age.
Parents
  • The TLS rules do allow the specification of a Service (i.e. a port), does Anydesk use a particular port that's not common or could you reconfigure it to do so? (And not sure if TLS looks before or after NAT if that's part of the equation.)

    Also, you can use source machine, so would it be possible to proxy Anydesk traffic through a particular machine on your network that will be exempted from TLS inspection?

    Just trying to think outside of the box. The problem is Anydesk it evidently a well-known vector for scammers and so if you open your door for it because you use it, I guess you're opening the door to be abused as well. No alternative to that janky app? It doesn't appear to provide anything that alternatives don't.

  • thanks yes, I don't like that tool either and it's only used by one workstation. but it is flooding the DPI log with those errors, already peaking out of the basic logs.

    From my reading, it should be able to fallback to port 80 if 443 does not work.

    I'll have to ask the user if it's working or not and if he could use alternatives.

Reply
  • thanks yes, I don't like that tool either and it's only used by one workstation. but it is flooding the DPI log with those errors, already peaking out of the basic logs.

    From my reading, it should be able to fallback to port 80 if 443 does not work.

    I'll have to ask the user if it's working or not and if he could use alternatives.

Children
No Data