Rules Meant To open any TCP port Leave all TCP ports closed [M967]

A. THE BUG/ISSUE (Varies from issue to issue)
[ol]- Summary - Give a clear summary in the topic subject, NOT here.

  • Can U reproduce the problem & if so how reliably?:
    Every time.
  • If U can, exact steps to reproduce. If not, exactly what U did & what happened:
    1:Install CIS → in default settings all TCP/UDP port closed, this ok.
    2:Advanced Settings->Security Settings->Firewall->Global Rules->Add new rule: Allow TCP or UDP In From MAC Any To MAC Any Where Source Port Is Any And Destination Port Is 49003 → Result: all UDP port closed except 49003, all TCP port closed 49003 too.
    3:Delete previous new rule->Stealth Ports->Alert Incoming Connections → Result: all UDP port open, all TCP port closed.
  • If not obvious, what U expected to happen:
    The TCP ports should be open.
  • If a software compatibility problem have U tried the conflict FAQ?:
  • Any software except CIS/OS involved? If so - name, & exact version:
  • Any other information, eg your guess at the cause, how U tried to fix it etc:
    I tried other ports, but always TCP closed.
    When remove all rules in Global Rules, then all UDP port open, but all TCP port closed.
    In previous version 6.3 was no problem.
    When disable firewall all TCP/UDP port open.
    Stealt Ports->Block Incoming Connections->Advanced Settings->Security Settings->Firewall->Global Rules->Edit:Block IP In From MAC Any To MAC Any Where Protocol Is Any->Enabled: Log as firewall event if this rule is fired → Result: never log any TCP connections, just UDP.

Two of the FW settings are non-standard - Trustconnect and ‘create rules for safe applications’. These may or may not be related to this issue.

A video showing this reproduction can be seen here:

[ol]- Exact CIS version & configuration:
CIS 7.0.315459.4132 default.

  • Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
  • Have U made any other changes to the default config? (egs here.):
    Just in Firewall Global Rules.
  • Have U updated (without uninstall) from CIS 5 or CIS6?:
    [li]if so, have U tried a a clean reinstall - if not please do?:
    I tried reinstall.
    [/li]- Have U imported a config from a previous version of CIS:
    [li]if so, have U tried a standard config - if not please do:
    [/li]- OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
    Windows 8.1 Pro 64 bit (up to date).
  • Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
    a=no b=no

[attachment deleted by admin]

Did you try moving the new rule to the top of the list?


When i add new rule, automatically put top of the list.
But UDP port open, TCP closed, when this rule put bottom of the list, UDP and TCP port closed.

  1. Could you say exactly how you are testing whether ports are open or closed please, in both step 2 and 3?
  2. Would you please append a screen shot of your global, application and zone rules.
  3. Are you trying to filter IPv4 or ipv6 packets?

Many thanks in anticipation


Firewall Settings:
Application Rules:
Global Rules:
Network Zones:
Blocked Zones:
IPv6 disabled, IPv4 manual:
Port Test (Vuze Client/Help menu/NAT Firewall Test):

Hi np

From your settings I cannot see any reason you should be experiencing the behavior you are - the TCP vs UDP differences are difficult to explain

So it seems like a bug

However it is puzzling that this has not been more widely reported. Two of your FW settings are non-standard - Trustconnect and ‘create rules for safe applications’. Although these should not cause the behavior you describe it may be worth trying reversing them to defaults then restarting, and retesting, as this might allow us to work out how to replicate the issue.

Best wishes


I tested again.
The rule don’t work. 49003 UDP open, 49003 TCP closed.
When disable firewall, 49003 UDP open, 49003 TCP open.


  1. Removed CIS v7, restart.
  2. Installed CIS v6, restart.
  3. Rule same as
  4. 49003 UDP open, 49003 TCP open.
  5. Removed CIS v6, restart.
  6. Installed CIS v7, restart.
  7. Rule same as
  8. 49003 UDP open, 49003 TCP closed.

TCP port can be test from some sites, example:
Rule same as
49003 TCP closed, when disable firewall: 49003 TCP open.

Removed Realtek driver → the problem not solved.
Installed back latest version.

When i enabled log in “Block IP In From MAC Any To MAC Any Where Porotocol Is Any” rule, i can see some blocked TCP records in Firewall Logs.
I created new rule and enabled log. Now can’t see any new TCP records in Firewall Logs.

What can i do more?

Thanks, that’s very thorough. Not quite the question I asked but very thorough :slight_smile:

I think this can be logged, at let’s see what QA say. Chiron could the tracker report highlight the non-standard FW settings please. (As identified in my above post).

Best wishes


np2359, I will forward this to the devs. However, can you please create and attach a diagnostics report to your first post. Also, please export your configuration and also attach that to your first post.

Let me know when you have done this, or if you have any questions.


Actually I have been following this thread because I am having similar issues(see this post). I thought that it may have been related to the recent addition of a router, but now that I see all the reports of problems with the upgrade to version 7 I am thinking that may be the problem. Basically what I am seeing is Vuze cannot accept incoming TCP connections, although UDP In works fine as well as UDP/TCP Out. I have disabled UPnP in Vuze and on the router, as well as set a static IP and forwarded the port(s). If I disable the firewall TCP In works. You can read through my thread for all the troubleshooting steps I have performed. If I have time I may try to reinstall v6 like np2359 since a clean reinstall of v7 did not help.

Hi np2359. Can you try running the Network status pluagin in Vuze? Plugins → Network status from the menu.
I get his when I run it:

Testing HTTP outbound Test successful Testing TCP outbound Test successful Testing UDP outbound Test successful Testing TCP port 62405 inbound Test failed: NAT test failed: Connect attempt to (your computer) timed out after 20 seconds. This means your port is probably closed Check your port forwarding for TCP 62405 Testing UDP port 62405 inbound Sending outbound packet and waiting for reply probe (timeout=5000) Sending completion event Test successful

Network Status plugin result same as, TCP test failed, when disable firewall: test successful.

Configuration and Diagnostics Report attached to first post.

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

Ok, then it looks like I am experiencing the same problem. I’m guessing I just did not notice the TCP In issue when I first upated to version 7, since Vuze is the only software in which I can actually see any problems.

I am also attaching an export of my configuration and a diagnostics report so the developers can have more to work with. I am using Comodo Firewall 7.0.315459.4132 on Windows 8 64 bit.

[attachment deleted by admin]

enfa20, thank you for noting that you are experiencing this as well. I have noted in the tracker that more than one user is experiencing the same issue.


Your welcome. I’m sure there are probably more people seeing this issue but may think it’s something else, like I did with the router. The tools in Vuze make it easy to troubleshoot the problem. I’m happy to test any solution the developers might offer.

I just updated to 7.0.317799.4142 today but I still see the same problem.

Not fixed in 7.0.317799.4142

Thank you for checking this. I have updated the tracker.

Do you have ‘create rules for safe applications’ ticked?

And have you changed the default trustconnect settings?

I note you are on Win 8 (not 8.1) 6.2.9200


“Create rules for safe applications” is not enabled. I have not changed the TrustConnect settings and I am not using WiFi. Yes I am still on Windows 8 but will be happy to update to 8.1 just to scratch it off the list. I had been holding off because of all the problems people had been having with 8.1 when it was first rolled out. However I would think the fact that I have not made changes to my OS during the time I experienced the TCP issue would be one less factor to consider. Also, np2359is running 8.1 and still seeing the same problem.