jzar2104

@Marcos It seems you're right. The same issue occurs with TeamViewer—these applications appear to need explicit blocking by their certificate signer. It's surprising how clever they are in bypassing security measures. Seems that the best and hardest approach for configuring a firewall is to block everything by default and manually control both inbound and outbound traffic.

@Marcos I send you the collected log via private message.

This is actaully what I am trying to figure out. It just should not happen... I use 'Automatic mode' with 'Also evaluate local Windows Firewall rules' disabled. Besides in netstat you have even: It's open only in trusted networks by Eset Endpoint default rule. 0:0:0:0 in netstat means 'any network'. Its really strange. Radmin is blocked on port 4899 without custom rule applied for it, whereas Anydesk not on port 7070. My Eset Endpoint version is 11.1.2039.2.

Hi everyone, I'm setting up a new set of firewall rules from scratch. At the moment, I'm working with the default configuration of ESET Endpoint, which only includes the built-in rule set. I have the option 'Also evaluate local Windows Firewall rules' disabled. I ran netstat -an to check which ports are open on my Windows test workstation: I tested the first application, Radmin Server, which requires port 4899 to be open. Without a firewall rule for it, despite the netstat result mentioned earlier, I cannot connect to the app, which behaves as expected. After applying a rule to allow incoming connections on local port 4899, it works properly. As you can see in the picture above, there is an application listening on port 7070. This is the AnyDesk Client. There is no built-in rule for port 7070, nor any custom rule allowing this app to connect on that port. However, AnyDesk works, and connections are accepted without issue. I used Wireshark to verify that it's indeed using port 7070: What am I missing? Is there another mechanism that could be allowing AnyDesk to connect? Kind Regards, J