Firewall Drops Connections without active blocking rule


  • Hello,

    in my company we use GPOs to configure our Windows 7 Firewall. In the Domain Profile, inbound and outbound traffic is completely open, except some special definied ports because we limited the hole domain traffic to the internet with an external hw firewall.

    Now sometimes (i guess about every 10-30 minutes) the problem occurs, that the DFW drops connections from the application "Hummingbird Exceed" (in different versions) . These connections where running without problems before and then suddenly one of the connections get dropped with an entry in the windows event log and the firewall log. In this entry you can see, that a port got blocked, which isn't defined in the firewall to be blocked. How is it possible that a connection got dropped when theres no rule for that action and the inbound and outbound traffic is allowed?

    Extract from the logs

    Windows Firewall:

    #Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

    2012-02-15 12:27:46 DROP TCP %srcip% %dstip% 57095 6000 41 AP 3803115154 1212165392 8820 - - - RECEIVE
    2012-02-15 12:27:47 DROP TCP %srcip% %dstip% 55858 6000 41 AP 3495703269 2868133190 8820 - - - RECEIVE

    Windows 7 Log:

    - <Event xmlns="">
    - <System>
      <Provider Name="Microsoft-Windows-Security-Auditing" Guid="x/>
      <TimeCreated SystemTime="2012-02-15T11:20:13.215441600Z" />
      <Correlation />
      <Execution ProcessID="4" ThreadID="56" />
      <Security />
    - <EventData>
      <Data Name="ProcessId">4784</Data>
      <Data Name="Application">\device\harddiskvolume3\program files (x86)\hummingbird\connectivity\13.00\exceed\exceed.exe</Data>
      <Data Name="Direction">%%14592</Data>
      <Data Name="SourceAddress">x</Data>
      <Data Name="SourcePort">59954</Data>
      <Data Name="DestAddress">x</Data>
      <Data Name="DestPort">6000</Data>
      <Data Name="Protocol">6</Data>
      <Data Name="FilterRTID">0</Data>
      <Data Name="LayerName">%%14610</Data>
      <Data Name="LayerRTID">44</Data>

    Wednesday, February 15, 2012 12:28 PM

All replies

  • Hi,
    I suggest you follow the steps below to check if the application has been enabled in Domain in Windows Firewall.
    1.       Click Start, click Control.
    2.       Open Windows Firewall, click Allow a program or feature through Windows Firewall.
    Please check if the application has been checked in Domain.
    If the application has been enabled in Windows Firewall, please temporarily disable Windows Firewall and check if the issue persists.

    I would like to share with you a useful article for your reference:

    Best regards,
    Della Li

    Saturday, February 18, 2012 2:14 PM
  • Hello Della Li,

    thank you for your answer. I did multiplie tests now and as result, one connection is still dropped after about 13 minutes, even if i allow every traffic in the wdf in and outgoing and have one additional allow rule for the specific port and no other rules (active or inactive). Curiously only one connection is been dropped even if i let the system running about 20 hours with multiple active connections.

    Thursday, February 23, 2012 8:35 AM
  • As we discovered, the service netprofm causes the trouble or is involved. The error also only appears on laptops with Intel network cards. No Problems on Desktops or VMWare (maybe Intel Anti Theft?). It looks like the service switches the network profile from domain to public and back. All except some Exceed connections where reestablished. Also some updater processes were restartet what can be seen in the event log (e.g. Adobe Updater)

    We are not really sure, how to act now. An idea was to disable the netprofm service while exceed is startet (which prevents the appearance of the Problem) and restart the service after the exceed.exe process is killed. Other way would be the complete deactivation of this service for affected clients what on the other hand means, they can't see their network status anymore. I didn't find out any other cons of this step especially because only ~8 Clients are affected.

    Does someone has additions to these conclusions?

    Wednesday, August 08, 2012 9:25 AM