4.2.35 installation/upgrade kills local network

Discussion in 'ESET Smart Security' started by LvR, Mar 11, 2010.

Thread Status:
Not open for further replies.
  1. LvR

    LvR Registered Member

    Joined:
    May 22, 2008
    Posts:
    31
    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?
     
  2. nattefrost

    nattefrost Registered Member

    Joined:
    Mar 12, 2010
    Posts:
    1
    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.
     
    Last edited: Mar 12, 2010
  3. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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. LvR

    LvR Registered Member

    Joined:
    May 22, 2008
    Posts:
    31
    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
     
  5. LvR

    LvR Registered Member

    Joined:
    May 22, 2008
    Posts:
    31
    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:mad:
     
  6. beynac

    beynac Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    21
    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!
     
  7. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    What message are you seeing in the firewall log after enabling logging of blocked connections in the IDS setup?
     
  8. beynac

    beynac Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    21
    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.
     
    Last edited: Mar 16, 2010
  9. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    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?
     
  10. beynac

    beynac Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    21
    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.
     
  11. beynac

    beynac Registered Member

    Joined:
    Aug 21, 2006
    Posts:
    21
    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?
     
  12. LvR

    LvR Registered Member

    Joined:
    May 22, 2008
    Posts:
    31
    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?
     
Thread Status:
Not open for further replies.