carmik 0 Posted May 18, 2021 Share Posted May 18, 2021 ESET Protect 8 (latest) and endpoint security 8 (latest) running on Windows 20H2 boxes happily, till yesterday. At that moment we discovered that social networking was not blocked for example. We have a general URL allow rule (whitelisted domains/URLs) followed by a category block rule that included various categories. Digging further it seems that all domains get characterized as not resolved ones. Indeed, by selecting to block only this category, everything (except our whitelisted domains) gets blocked. Has something changed in the infrastructure, is this a known issue? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,071 Posted May 18, 2021 Administrators Share Posted May 18, 2021 First of all make sure that ekrn can communicate with ESET's servers on port 53535. If that's not an issue, carry on as follows: - enable advanced Web Control and network protection logging in the advanced setup -> Tools -> Diagnostics - reboot the machine - reproduce the issue - disable logging - collect logs with ESET Log Collector and upload the generated archive here. Link to comment Share on other sites More sharing options...
carmik 0 Posted May 18, 2021 Author Share Posted May 18, 2021 Marcos, I've found out that we've run into a similar situation that we had about a month ago: some proxy perhaps in our infrastructure is blocking queries to resolve/categorize links and sites. I've reproduced this issue on another site, not administered by me. Is there some sort of eset tool that checks availability of services provided by the eset infrastructure and presents them in an easily translatable form (for example works/does not work)? Which servers/protocols are used to query URL categories? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,071 Posted May 18, 2021 Administrators Share Posted May 18, 2021 Please read https://support.eset.com/en/kb332: In order for Web Control to work and resolve categories it is important to allow access to: Make sure to open UDP port 53535 for the addresses in the table below and allow requests to your local DNS server (UDP/TCP port 53). Hostname IP address h1-arsp01-v.eset.com 91.228.166.42 h1-arsp02-v.eset.com 91.228.166.43 h3-arsp01-v.eset.com 91.228.167.141 h3-arsp02-v.eset.com 91.228.167.142 h5-arsp01-v.eset.com 38.90.226.14 h5-arsp02-v.eset.com 38.90.226.15 Link to comment Share on other sites More sharing options...
carmik 0 Posted May 18, 2021 Author Share Posted May 18, 2021 1) Some tool I can check connectivity to these address over 53535/udp? 2) What should I look for on my local DNS? Link to comment Share on other sites More sharing options...
carmik 0 Posted May 18, 2021 Author Share Posted May 18, 2021 @Marcos I've PMed you. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,071 Posted May 18, 2021 Administrators Share Posted May 18, 2021 5 hours ago, carmik said: @Marcos I've PMed you. It looks like a query to 91.228.166.42:53535 and 91.228.167.116:53535 failed. A fallback to http failed too: Failed to open HTTP CONNECT tunnel. Connections to Google DNS failed too: Failed connect to 8.8.4.4@53 (UDP) Failed connect to 8.8.4.4@53 (TCP) Is this communication allowed on the proxy and firewall? I also see that http proxy 10.xxx.xx.17 is used, maybe it's causing the issue. Link to comment Share on other sites More sharing options...
carmik 0 Posted May 21, 2021 Author Share Posted May 21, 2021 Apologies for my late reply. On 5/18/2021 at 3:28 PM, Marcos said: It looks like a query to 91.228.166.42:53535 and 91.228.167.116:53535 failed. A fallback to http failed too: Failed to open HTTP CONNECT tunnel. Connections to Google DNS failed too: Failed connect to 8.8.4.4@53 (UDP) Failed connect to 8.8.4.4@53 (TCP) Is this communication allowed on the proxy and firewall? I also see that http proxy 10.xxx.xx.17 is used, maybe it's causing the issue. I will raise an issue with my provider. However: 1) Regarding http fallback to 91.228.166.42, I tried to open https://91.228.166.42 from my home connection as well as from another place and that failed. How can I (or the ISP sysadmins) easily tell that https access to these systems work? Asking here because from the looks of it, it is impossible to connect "normally" regardless of your (network) location (home/business). 2) Why is Google DNS used at all? This is a centralized and controlled environment. As such, your client should not try to connect to any DNS, apart from the provisioned one. Link to comment Share on other sites More sharing options...
carmik 0 Posted May 21, 2021 Author Share Posted May 21, 2021 Apologies for my late reply. On 5/18/2021 at 3:28 PM, Marcos said: It looks like a query to 91.228.166.42:53535 and 91.228.167.116:53535 failed. A fallback to http failed too: Failed to open HTTP CONNECT tunnel. Connections to Google DNS failed too: Failed connect to 8.8.4.4@53 (UDP) Failed connect to 8.8.4.4@53 (TCP) Is this communication allowed on the proxy and firewall? I also see that http proxy 10.xxx.xx.17 is used, maybe it's causing the issue. I have tried from home to connect with a browser to one of these systems over https. It failed (I presumed something needed was missing to establish a successful connection) when I tried this at home. I still think that eset should provide a utility to easily identify what is/isn't reachable from the ESET infrastructure. It will help both detection and isolation of the problem, as well as help whoever performs corrective actions to verify that things have worked. I have raised an issue with the WAN admins, but lack of an utility like this means that they will not be able to actually tell whether thinks have been fixed or not (at least on their side). 10.xx.xx.17 is the eset protect server, which hosts the apache module for caching traffic (updates etc): so nothing special there. One other question: why is the client trying to resolve things via Google DNS? Is this a fallback mechanism? Link to comment Share on other sites More sharing options...
Recommended Posts