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?:
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.
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:
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.
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 http://www.bountyhunters.hu/cis6.jpg and enabled log. Now can’t see any new TCP records in Firewall Logs.
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
Testing TCP outbound
Testing UDP outbound
Testing TCP port 62405 inbound
Test failed: NAT test failed: Connect attempt to 184.108.40.206:62405 (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
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.
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.
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.
“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.