4.2.35 installation/upgrade kills local network

I have a router/modem with DHCP via DSL for Internet access and 3 wired machines forming a small home network - one W7 x64 machine and two XP SP3 X86 machines.

With 4.0 and before, I had no problems with the network at all - INTERNET and network both served me well.

Soon as I install 4.2.35 on the W7 machine, the local network is screwed - I cannot see any other machine and the other machines cannot see me - they all still have INTERNET access though.

Try as I might, I just cannot get the network running again.

If I remove 4.2.35 and re-install 4.0, my network immediately starts functioning again - and this is without me changing any settings at all

Again upgrade to 4.2.35 and the network is immediately screwed.

Can somebody with more intelligence than me suggest what I did wrong or how to make things run with 4.2.35?

 

i have the same problem with 4.2.35. My network connection via netgear router was disabled on the alt pc. I had to revert back to 4.0 and everything was running smooth once again ....hope this gets fixed.

 

Please confirm or deny that you have the same firewall module version installed with both v. 4.2.35 and v. 4.0.474

 

4.0 installs some other version initially, but eventually after all updates got applied again, both 4.0 (with a working network) and 4.2 (with a non-working network) run off 1056 ................

Disabling the firewall (allow all coms) doesn't help the situation with 4.2 either

 

Not sure why I have to manually be made to jump through hoops to make a simple local network run again.

Its obvious that this issue was present during the beta phase and never got addressed properly.

I can sort my own problem by applying this fix, but I am no boffin and don't appreciate the implications of my actions and possible rendering useless of the paid for firewall

 

Is there any news regarding this problem? I've tried the workarounds (as far as I could understand them) and still can't connect to my other workgroup computers (and vice versa) since installing the new version of ESS.

My computer: XP with ESS 4.2.35.0
Workgroup computers: One with XP, one with Vista: both using Kaspersky Internet Security.

I am a novice regarding networking, protocols, ports etc. and would really like to get this fixed without me having to mess about with the security system on my computer, especially when I don't understand what I'm doing!

Please could we have a fix for this!

 

What message are you seeing in the firewall log after enabling logging of blocked connections in the IDS setup?

 

This is weird! Before shutting down earlier, I switched the firewall to 'Interactive' and, without me allowing anything, the network connected OK, but only after a short while (ie not immediately). I've just started up the computer and the network seems to be still working. here are some sample log items.

Code:

16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18868	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18862	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18857	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18852	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18848	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18844	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 16:30:47	Communication denied by rule	192.168.1.254:18844	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests

16/3/2010 16:32:04	Communication denied by rule	192.168.1.67:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 16:32:03	Communication denied by rule	192.168.1.67:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 16:32:02	Communication denied by rule	192.168.1.67:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 16:32:02	Communication denied by rule	192.168.1.67:138	192.168.1.255:138	UDP	Block incoming NETBIOS requests		


16/3/2010 20:06:49	Communication denied by rule	192.168.1.68:60983	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 20:06:46	Communication denied by rule	192.168.1.68:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 20:06:46	Communication denied by rule	192.168.1.68:60983	239.255.255.250:1900	UDP	Block incoming SSDP (UPNP) requests		
16/3/2010 20:06:46	Communication denied by rule	192.168.1.68:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 20:06:46	Communication denied by rule	192.168.1.68:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 20:06:44	Communication denied by rule	192.168.1.68:137	192.168.1.255:137	UDP	Block NETBIOS Name Service requests		
16/3/2010 20:06:43	Communication denied by rule	192.168.1.68:49968	239.255.255.250:3702	UDP	Block incoming Web Services Discovery  (WSD) requests		

The first block was when I couldn't connect. The second is as I started the computer and the third is when I was able to connect.

 

I got the same message with the trusted zone set up improperly. Does adding the subnet 192.168.1.0/255.255.255.0 to the trusted zone help?

 

I have already added that subnet.

I looked at the knowledge base and one of the answers said to make sure that all services were ticked in 'IDS and advanced options'. Some of mine were not. I ticked them all and then reset everything to default settings. Some then became unticked again. It looks as if the default settings for this version could be incorrect.

It is difficult for me to see what effect this has had, as the networked computers were connecting anyway. However, I have now stopped getting entries in the log. I've rebooted a couple of times and everything still works. So, I think that I had better leave things alone unless I have further problems.

Many thanks.

 

To add to my previous post:

With the default settings, the following services were NOT ticked:
Allow UPNP in TZ
Allow incoming streams from the Internet via IGMP protocol
Maintain inactive TCP connections
Allow communication for bridged connections

Is it OK to tick all of these?

 

So here's the thing then:

I accept your explanation, but why is it that the trusted zone is set up properly with 4.0 and working with no problems, yet as soon as you install/upgrade to 4.2 suddenly the trusted zone is "set up improperly" - iow the mere act of installing 4.2 causes this?

How am I supposed to know what is and what is not "properly" - surely the update/installation process must know what to do and "how to set it up properly" so that the user must not be required to fiddle and fudge with settings he knows nothing about?

................... see my previous report - what is the implication of my actions in order to restore the local network's functionality?