Results 1 to 4 of 4

Thread: V7.0.408.0 trusted zone connectivity fails

  1. #1
    colinbutcher Guest

    Default V7.0.408.0 trusted zone connectivity fails

    After upgrading to v7.0.408.0 (which incidentally has what seems to be better performance than previous versions) my local trusted zone network connectivity fails some time (about 30 minutes or so) after a system boot. Typically I might be copying files from one Windows box to another (Win XP Pro) and then it will simply quit part way through and subsequently fails to reconnect, even if ZISS is shutdown on both boxes.
    However, boot without ZISS starting at all - and all is well.
    I suspect that ZISS is modifying some setting in the TCPIP stack and that it remains set even when ZISS is shut down. This is a bad thing.
    The best clue I've found is that the Event Viewer is (and only since upgrading to V7.0.408.0) showing TCPIP errors: "TCP/IP has reached the security limit imposed on the number of concurrent connection attempts" - event ID 4226. Here's the background information from the Microsoft web site about this:
    Details Product: Windows Operating System ID: 4226 Source: Tcpip Version: 5.2 Symbolic Name: EVENT_TCPIP_TCP_CONNECT_LIMIT_REACHED Message: TCP/IP has reached the security limit imposed on the number of concurrent (incomplete) TCP connect attempts.


    The TCP/IP stack in Windows XP with Service Pack 2 (SP2) installed limits the number of concurrent, incomplete outbound TCP connection attempts. When the limit is reached, subsequent connection attempts are put in a queue and resolved at a fixed rate so that there are only a limited number of connections in the incomplete state. During normal operation, when programs are connecting to available hosts at valid IP addresses, no limit is imposed on the number of connections in the incomplete state. When the number of incomplete connections exceeds the limit, for example, as a result of programs connecting to IP addresses that are not valid, connection-rate limitations are invoked, and this event is logged.

    Establishing connection rate limitations helps to limit the speed at which malicious programs, such as viruses and worms, spread to uninfected computers. Malicious programs often attempt to reach uninfected computers by opening simultaneous connections to random IP addresses. Most of these random addresses result in failed connections, so a burst of such activity on a computer is a signal that it may have been infected by a malicious program.

    Connection-rate limitations may cause certain security tools, such as port scanners, to run more slowly.

    User Action

    This event is a warning that a malicious program or a virus might be running on the system. To troubleshoot the issue, find the program that is responsible for the failing connection attempts and, if the program might be malicious, close the program as follows.

    To close the program
    1. At the command prompt, type
      Netstat no
    2. Find the process with a large number of open connections that are not yet established.
      These connections are indicated by the TCP state SYN_SENT in the State column of the Active Connections information.
    3. Note the process identification number (PID) of the process in the PID column.
    4. Press CTRL+ALT+DELETE and then click Task Manager.
    5. On the Processes tab, select the processes with the matching PID, and then click End Process.
      If you need to select the option to view the PID for processes, on the View menu, click Select Columns, select the PID (Process Identifier) check box, and then click OK.
    <hr>Currently there are no Microsoft Knowledge Base articles available for this specific error or event message. For information about other support options you can use to find answers online, see

    Looks like a bug or some invalid assumptions in the ZISS code to me. The bit about performance related effects probably applies to ZISS too. Needs fixing please.

    Meantime - it might be possible to develop a work-around by changing some TCPIP stack related registry value. Anyone know what or where?

  2. #2
    colinbutcher Guest

    Default Re: V7.0.408.0 trusted zone connectivity fails - update

    Having found this:;url=downloads
    and increased the number of open connections from the embedded value of 10 to 100 - it made no difference to the problem I'm getting when trying to copy files.
    The error message on the machine doing the copying (from remote machine to local disc) is: &quot;Cannot copy &lt;filename&gt;: The specified network name is no longer available.&quot;
    The error message on the machine doing the copying when attempting to connect to the source machine is: &quot;<a href>\&lt;machine&gt; is not accessible. You might not have permission to use this network resource. Contact the adminisrator of this server to find out if you have access permissions. The specified network name is no longer available.</a>"
    There are no errors reported in the Event Viewer on either of the two machines.
    The problem persists if ZISS is shut down at this point on both machines. The only thing that unblocks access is restarting both machines with ZISS disabled, which rather negates the point of using a firewall!
    So, what's the ZISS firewall up to and why is it deciding to block file copying and access to the remote machine after a period of time, especially while file copying is actually in progress?

  3. #3
    Join Date
    Nov 2004

    Default Re: V7.0.408.0 trusted zone connectivity fails - update

    Hi!better you contact directly the ZA technical support at: They will guide you and try to troubleshoot your problem.Cheers,Fax

    Click here for ZA Support
    Monday-Saturday 24x6 Pacific time
    Closed Sundays and Holidays

  4. #4
    colinbutcher Guest

    Default Re: V7.0.408.0 trusted zone connectivity fails - update

    I've had no reply from the technical support folks on this subject yet, other than the usual &quot;how are we doing&quot; survey. I see plenty of similar sounding issues in the forum too.
    I simply don't have the time to debug and diagnose other people's code that should have been better tested before being released. I have enough to do with my own work designing systems and software and running large complex projects in mission-critical environments.
    So, I've given up on ZA and moved to AVG. Still in the trial period, but so far it has a lot less overhead (thus a way more responsive xw9300 workstation) and hasn't (yet) bitten me in an unpleasant and difficult to resolve manner. Time will tell.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts