Hello.. I've encountered something strange (using newest OPF v4).
A time ago I guess the application rules was updated to include NOD32 proxy connection (30606) when used by an application.
The automatic rule is (using IE as an example):
Internet Explorer outbound through Eset NOD32
Where the protocol is TCP
and where direction is Outbound
and where remote host is Macro:MY_COMPUTER (currently 192.168.1.2;127.0.0.1;127.0.0.0)
and where remote port is 30606
The above rule will not work here, the logs shows it doesnt block
either, it just does nothing with the connection at all.
For some reason replacing the Macro:MY_COMPUTER with 127.0.0.1 makes the
above rule work. My question is why, and is there others with my problem?
I'm on a router with the address 192.168.1.1, and the computer has the static address 192.168.1.2.
I guess there's no problem mentioning the ip's above here because they are local to my "network".
The new feature of NOD32's proxy made me go back to v 2.7 several months ago. Since then I haven't yet explored v3 more fully mainly because of the OP betas and product change.
I've never used a proxy server so I'm not quite sure of the issued involved with it. However, I came to the preliminary conclusion that it would be easier if the web proxy function was turned off and let the firewall function normally. I like the equivalant IMON feature, but frankly it is superflous since it actually causes things to be scanned twice. Once on the download and then when it executes. It's nice, but not needed since if the engine is going to trigger for malware exactly when that happens is not a critical issue.
That's my long winded way of saying that I don't understand what the heck is going on either.
I'm not too satisfied with how things work in 3.0 either. It seems just plain wrong to choose whether the firewall should work properly, or if the AV should.
Default settings in NOD32 + FW essencially disables the firewall for everything running on port 80 + 2 others. This is currently discussed rather heavily in the Eset's forums..
However, I've tried to configure the AV to just use proxy on Opera, FF, and IE, where its most needed, and this seems to work when the mentioned address is changed.
No idea why it behaves the way it does though.. Maybe it for some reason doesn't try to match with all addresses in the macro or something. Just a thought.
If it hadn't been for the bad interface, logs, lack of plugins, etc compared to v4 I would've installed v2008 a long time ago (which might have fixed this strange issue).
I guess a year or two from now v2008 might be comparable to what v4 is and has been for a long time. Hopefully.
These two addresses (127.0.0.1 and 192.168.1.2) should be functionally equivalent for you. I'm not sure I understand why it doesn't work. However, there are some differences in the two according to IANA:
127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere [RFC1700, page 5].
192.168.0.0/16 - This block is set aside for use in private networks. Its intended use is documented in [RFC1918 (http://tools.ietf.org/html/rfc1918)]. Addresses within this block should not appear on the public Internet.
http://tools.ietf.org/html/rfc3330
Perhaps when a proxy is involved the 127.0.0.0 address is "more" your computer then the private network address. One is a loopback address while the other is a Private Address Space which should be functionally equivelant. I don't understand the intricacies of this well enough to give a real explanation but the difference between the addresses may cause slight perturbations.
@Manny,
I've tried to recreate the rule manually, in case OPF does something else in addition to just autocreating the rule, but without luck.
I've noticed one thing though.. In the log everything from Opera, Firefox, IE (the browsers set to go through the AV) shows as the process 'n/a' in the log, but 'Network activity' shows the correct process name.
When using the ip 127.0.0.1 in the rule everything is ok (still shows as n/a in the log though), showing the correct rule name, otherwise every connection to 30606
shows first with the correct rule name, then 'Learning mode', then the rule name again, while doing nothing.
Other rules use Macro:MY_COMPUTER with success, apparently only rules regarding the NOD32's proxy won't work with it.
The new feature of NOD32's proxy made me go back to v 2.7 several months ago. Since then I haven't yet explored v3 more fully mainly because of the OP betas and product change.
I've never used a proxy server so I'm not quite sure of the issued involved with it. However, I came to the preliminary conclusion that it would be easier if the web proxy function was turned off and let the firewall function normally. I like the equivalant IMON feature, but frankly it is superflous since it actually causes things to be scanned twice. Once on the download and then when it executes. It's nice, but not needed since if the engine is going to trigger for malware exactly when that happens is not a critical issue.
That's my long winded way of saying that I don't understand what the heck is going on either.
The main difference between the two addresses is that 127.0.0.1 is an internal address, only within the computer. The other address is an external address used by the LAN partners.
While both addresses are indeed for the computer, one is the computer talking to itself and the other allows others to talk. There has been some confusion between "my address" and loopback before. The most recent I recall was ATI used "My_address" instead of loopback for the Catalyst software. Allowing loopback in firewalls did not let the program work correctly.
With Manny, I do not know why allowing either address within the rule would not work unless Outpost mistakenly checks the LAN address and blocks without checking the loopback adapter's address.
With Manny, I do not know why allowing either address within the rule would not work unless Outpost mistakenly checks the LAN address and blocks without checking the loopback adapter's address.
This is the thing that confuses me most.. It doesn't block, at least it doesn't say so.
It seems to find the autocreated rule which it uses for a second (without making a connection) before returning to learning mode, and this results in it being _ignored_ totally for some unknown reason.
...
If it hadn't been for the bad interface, logs, lack of plugins, etc compared to v4 I would've installed v2008 a long time ago (which might have fixed this strange issue).
I guess a year or two from now v2008 might be comparable to what v4 is and has been for a long time. Hopefully.Well, 2008, or any other firewall, wouldn't make any difference. The proxy is a design feature in NOD3 that will impact any firewall. You know 2.7 is still available and probably will continue to be for a while since it works in Win98 unlike V3. It uses the same engine so the protection is the same.
 I could use some help again...
 Lost Licences |
Why is connection to NOD32 proxy blocked when using the auto rule?