mackintire 3 Posted April 22, 2016 Share Posted April 22, 2016 The client machines are on the domain. When we disable this setting in policy: "Do not ask for protection type of new networks. Automatically mark new networks as public." The ESET firewall gets stupid 50% of the time and changes the profile to Network #, even though the machine is on the domain and the windows network profile is known by windows labeled "work/company.local" Three choices for windows are public/private/domain. Basically if we leave the setting enabled, the system correctly identifies or defaults our network as being safe possibly because we also have it saved as a known/trusted network. If we disable this setting, the system ignores windows (domain firewall profile IS was in effect according to windows before ESET takes it over) and decides that the local network is a new one. Company.local configured as public??? There's no apparent rhyme or reason to this. I deployed this to 20 developers and 6 were locked out on the next restart. All of them are connecting through the same VPN concentrator so the source IP is the same... I ended up logging into 6 machines to change the profile to home/work. This sucks for our traveling developers and us for deployment, as we want everything to work, in house, and give them the choice when connecting at a different location if the network is safe or not. Disabling this setting, gives them the choice and breaks the local network.....until we go into each affected client and manually change the network connection type Enabling this setting, prevents them from having a choice and makes it difficult or impossible for them to work in the field without completely turning off the firewall. (Because all new networks are treated as hostile, "public") My workaround is creating ANOTHER profile with this one difference and manually fixing all the affected machines. Please fix this. If a machine is on the domain, ESET should NOT default to public network when you disable this feature. OR fix the detection for what the state was before this setting is enabled, users should not be locked out by changing this setting, as this setting should be for NEWLY detected networks and not ones that you are already connected to. The network hasn't changed. Or is this feature just broken? Link to comment Share on other sites More sharing options...
mackintire 3 Posted April 25, 2016 Author Share Posted April 25, 2016 Usually ESET responds fairly quickly... I'm guessing that they never tested this.... and need to check/test. Link to comment Share on other sites More sharing options...
ESET Staff MichalJ 434 Posted April 26, 2016 ESET Staff Share Posted April 26, 2016 Hello, As of now, when you sets "Do not ask for protection type of new networks. Automatically mark new networks as public." - each new network is recognized / marked as public in ESET firewall, regardless the Windows settings. Solution is only by importing the list of networks which are marked as home/work, all others will be marked as public. Other option is to not enable the checkbox, however a popup will be displayed to the user, and unless he has admin privileges, he would be able to mark networks only as public. For the future MAJOR (7) generation of Endpoint, product will be able to overtake the network preferences from Windows (this seems to be the feature you want). It will be first time included in ESET Consumer products V10, which are scheduled for release in Q3/Q4 2016. Endpoint 7 will inherit some of the changed behavior, including this, but as of now, there is no clear time set, except the fact, that it will be fore sure in 2017. Hope that this helps. Link to comment Share on other sites More sharing options...
cpetry 4 Posted April 27, 2016 Share Posted April 27, 2016 I wish ESET would stop putting all of this effort in home product betas and focus on the business sector. It's crazy how bug laden the business 6.3.X products still are. I'm waiting on an ESET tech to call/email me so we can go over my concerns with the ESET Endpoint Security firewall. I want it enabled so it can detect and block file coder activity (requires the networks scanner which is apparently built into the firewall). Now I'll have to look out for this issue the OP is talking about. I was hoping to set my domain.local as the home/business network so LAN communication isn't blocked with the firewall on automatic mode. I just don't want it stopping the service desks remote control softwares. Link to comment Share on other sites More sharing options...
mackintire 3 Posted April 27, 2016 Author Share Posted April 27, 2016 So I figured out, it the DNS suffix flag detection works as long as the IP address is being picked up via DHCP. It does not appear to work if you set the IP address static. Lots of undocumented gotcha s in the product still. Link to comment Share on other sites More sharing options...
cpetry 4 Posted April 27, 2016 Share Posted April 27, 2016 That's good to know.. At least that means for the most part that should work for us. Our workstation LAN is DHCP. We rarely hand out statics. If we hand out a static, it's because we are actually blocking that user from the network due to bad behavior and we don't want the blocked IP to float. So, if we had to, and I've mentioned it internally, we create known networks for each of our sites, and base those ones off of the DNS address being used at each site (which is normally the IP of that sites domain controller..) Link to comment Share on other sites More sharing options...
mackintire 3 Posted April 27, 2016 Author Share Posted April 27, 2016 Another strange issue I was able to resolve, was the firewall rules not consistently being applied when I used the "192.168.1.0/255.255.255.0" syntax "192.168.1.0/24" works even though both syntax are supposed to be valid. I discovered this while trying to debug why communication to a trusted subnet wasn't working. Once placed into interactive mode, the system created a rule that used the 1.1.1.0/24 syntax for the same rule I already had defined as 1.1.1.0/255.255.255.0 So I deleted the new rule and changed the original one to the alternate syntax. It's stuff like this that drives me nuts... Link to comment Share on other sites More sharing options...
cpetry 4 Posted April 28, 2016 Share Posted April 28, 2016 (edited) Yeah, I want the known networks list to have the ability to populate the trusted zone. This way if you put in a catch-all subnet, it's only in that trusted sites zone as long as you're within a known network. Say you're corporation "domain.local" uses 192.0.0.0 addressing scheme (it likely doesn't but this is an example); I should be able to list domain.local as a home/work "known network" and list 192.0.0.0/32 as the catch-all subnet for my entire network. Then, that catch-all would only populate into the trusted sites zone if the computer identified the network as the known network, you're home/work network. You could then go a step further and setup network authentication so that it's 100% solid. This way as long as your clients are on domain.local, and you had your catch-all subnets (one or more) listed, it would treat the entire network, not just one site, as the trusted zone, while only on the known network. If the endpoint went off of the known network, it would be marked as public, and that automatic population of the trusted sites zone, those catch-all addresses, would be pulled from the list, because they are only associated with the known network. If you paired that with network authentication, you wouldn't have to worry about hackers mimicking your corporate environment, as they would be missing the network authentication component, even if they copied your DNS suffix or subnetting. As it stands, the personal firewall in Endpoint Security 6.3.X isn't suited/fit for corporate use in my opinion. If you're someone who manages very large scale networks and has several dozen subnets, you will quickly come to the conclusion that the firewall in ESET Endpoint Security 6.3.X wasn't suited for a large scale corporate network. It would work much better for a very small company with a single site or a home user. ESET in my opinion is confusing "home/work network" with the term site. What they have defined as a "home/work network", one subnet, the subnet the client is running on, is NOT the corporate network, it's the site the endpoint happens to be running on. Edited April 28, 2016 by cpetry Link to comment Share on other sites More sharing options...
cpetry 4 Posted April 29, 2016 Share Posted April 29, 2016 I think I was able to find a way to do the above. It's not documented. I know it's not because I went looking and clicked on all of the ?'s in the interface to see what each field did. I had to guess and hope. lmao It turns out inside of a home/work "known network" that field labeled "additional trusted networks" can actually take the catch-all addresses. So I was able to slap a catch-all subnet in there and I can now ping clients at other sites. Now I'm going to take this further and install the ESET Network Authentication app for added security. Link to comment Share on other sites More sharing options...
Recommended Posts