Jimbo151

Hi Peter, Thanks for the reply - when creating a firewall rule to allow the localhost connection I haven't been able to do it without the source being set to 'All' and the direction inbound. Is there a way to specify the local machine as the source within a rule ? When looking at the block event in the log it does not show a source address, just the dynamic source port and I don't see a way to specify 'itself' as the source with in rule 03/01/2020, 15:14:31 No usable rule found [::]:49830 [::1c1e:c2a6:0:0]:80 TCP root

After upgrading Mac clients from ESET Endpoint Security 6.8.2.0 to ESET Endpoint Security 6.8.400.0 the firewall blocks access to local services running on the same machine access via 'localhost' This can be reproduced by the following process. Under ESET 6.8.2.0 run 'sudo apachectl start' and open hxxp://localhost in any browser and it should display 'It Works!' in the browser After updating to ESET 6.8.400.0 the same process times out and the following is logged in the firewall log 03/01/2020, 15:14:31 No usable rule found [::]:49830 [::1c1e:c2a6:0:0]:80 TCP root We have a number of use cases where services are connected to on the local machine which are now broken, I have been unable to craft a new firewall rule to fix this without specifying the source as 'ANY' which is unacceptable for an inbound connection. what has changed from 6.8.2.0 to 6.8.400.0 that is stopping the machine from connecting to services running on itself ?

Hi TomasP Thank you for pointing that channel out I wasn't previously aware it existed - am now subscribed to it.

Any official comment ? Surely for the release that fixes such a vulnerability would have been mentioned on the forums as a critical fix whereas the latest product release post for MAC OS is still showing 6.3.85.1 Paying customers would have had some communication of the importance of upgrading to 6.4.168

Hi, We have a number of IOS developers who have reported that their IOS Simulators are unable to access any URL from with various simulators while Web Access Protection is enabled on their Macs. One of the affected applications is xcode 7.3, this is installed on OSX 10.11.6 and running ESET AV Client ver 6.2.7.0. With Web Access Protection enabled it is not possible to access any HTTP URL via Safari or Apps running within the Simulator. Is there a way to allow selected Apps to by-pass Web Access Protection without disabling it for the entire machine ? 6.2.7.0 has improved our experience with Web Access Protection on Macs in a lot of areas but there are still issues that means we have to disable it.

We had a similar issue when rolled out ESET a couple of weeks ago. It affected about 3% of clients. We found it was due to corruption in the .ost file, scanpst did not manage to repair so we had to re-create the .ost. We are using o365 with outlook 2010 We don't know if the initial eset scan caused the issue or exaggerated an existing condition that up that point was not causing a problem.

ESET started blocking access to all HTTPS websites for us at about 11:30 this morning on windows 7 clients. This affected internal and external websites. We had to turn off Web Access Protection. Can we get a reason as to why this has occurred - the post above mentions LiveGrid - is this a cloud based service ? Why would this suddenly decide to block access to internal https webservers ? The solution of asking 250 users to reboot would not go down well !