Custom Rule Not Applying

We've noticed a number of times that, despite having created a custom firewall rule, that rule is not applied, and instead ESS pops-up a warning dialog box asking what to do.

If we permanently allow the traffic via the warning dialog box (remember action or create custom rule), another, duplicate rule is created.

Take a look at this ESS warning dialog box:

​

Here's a rule that was created before we got the ESS warning:

​

For some reason, the rule did not apply to allow the traffic.

It should be noted that the rule does not restrict IP addresses (whereas the warning dialog box specifies an IP address), but we've had rules that are specific to the IP address displayed in the ESS warning dialog box, yet don't apply.

Also note: the ESS warning dialog box shows protocol "TCP & UDP". When trying to create a rule using this dialog box (remember or custom), ESS pre-populates the rule with protocol "TCP" (# 6). Whether the rule is "TCP" or "TCP & UDP" -- we've even tried having 2 simultaneous rules, one for each -- the rule is not applied and an ESS warning dialog box pops-up.

A couple observations:

1) this "rule not applying" situation usually occurs once, after rebooting; after a new (duplicate) rule is created it seems ESS does apply that new (duplicate) rule; if a new rule is not created, the warning dialog box continues to pop-up; after rebooting, even the new (duplicate) rule is not applied (with the exception noted in #2, below)

2) the application in question is on a drive (D: drive) that must be mounted after rebooting; this usually happens via Task Scheduler, but when it doesn't, we have to manually mount it; it appears (though not confirmed) that the "rule not applying" situation occurs when, after a reboot, the drive does not automatically mount

Any thoughts on why an existing rule is effectively ignored?

.

 

Bump.

Anybody?

.

 

Not sure if it works, but try setting the port on the local side to 110 and removing all entries on the remote side. Although I can't see why this rule wouldn't work either.

 

I'd suggest contacting customer care and supplying them with the following stuff:
- ESS configuartion exported to xml
- SysInspector log
- both dat files from the "%ALLUSERSPROFILE%\Application Data\ESET\ESET Smart Security" folder

If they don't find anything unusual, it'd be great if you could also create a Wireshark log with the communication captured.

 

@dmaasland, thanks for the suggestion; tried it, but that rule, too, was overlooked.

As for dealing with the whole config / sysinspector / dats / logs / ethereal / try-this-and-that-setting / reinstall / etc, we've gone down that path before, for multiple issues, only to get no final resolution -- hugely inefficient.

We don't have time to repeatedly check the obvious [level 1 tech support scripts], nor to be unpaid application testers [help us find the answer & it'll help all our other users], nor to go thru many system reboots just to try something on the off chance the issue will go away [dealing with a symptom & not addressing the cause].

I'm all for helping out -- after all, isn't that what forums & giving back & the golden rule are all about -- but when it starts to impact our business, we've got to make a choice.

I think we're headed for a different firewall. Probably will keep Eset for anti-virus / real-time protection, but discontinue its use as a front-line defender.

We scanned our system using no fewer than a half dozen different anti-malware applications, and it seems our system has not been infected. From this, we're convinced that Eset produces top-notch tools that do keep us safe.

However, we're forced to look elsewhere for a firewall due to:

• config settings get corrupted (it's happened several times)
• firewall rules get ignored (this thread)
• dialog boxes are missing information & don't allow us to do what we should be able to do (another thread -- https://www.wilderssecurity.com/showthread.php?t=294635 -- turns out that issue has resurfaced)
• logs grow to >1 GB (even though set to delete every 1 day) & make the GUI unresponsive
• the technical teams aren't able to resolve our issues (without considerable effort on our part, effort that includes providing detailed, confidential information about our systems)

We don't know why firewall rules are not being followed, but for now we'll keep making new (duplicate) rules until we get a replacement firewall.

This thread can be closed.

.

 

Could you please get all the stuff mentioned in my previous post, including a Wireshark log from a communication where you're prompted twice to create a rule, compress the files to an archive and contact me for further instructions?