Can't listen on port 25565


I am having an issue where CISv7 is blocking traffic on a port needed for a local server. Specifically, I have a Minecraft server listening on port 25565, but clients from WAN/LAN cannot connect. Here is my setup:

  • Local server (listening for TCP connections at
  • Remote LAN client (connecting from

Port 25565 is forwarded correctly on the NAT. All relevant server applications are configured as “Allowed Application” in the Application Rules, and I also have a Global Rule set to allow incoming traffic (“Allow TCP In From MAC Any To IP Where Source Port Is Any And Destination Port Is 25565”). The global rule is in an appropriate position (above blocking rules).

Here is what I’ve noticed:

  • Disabling the firewall completely will allow clients to connect normally. Obviously, I don’t want to have my firewall off forever, but this at least seems to indicate that the issue is with my firewall setup instead of the router/connectivity/application
  • I had previously been able to host the server without issue a few months ago; I believe since then the firewall has updated, but I had not touched any rules since then
  • The CIS logs show entries where application “Windows Operating System” (TCP from to is being blocked; however, the server is definitely listening on the port (verified in Comodo Killswitch, as well as in “netstat -a”)

What am I missing?

You have in rules for app - to accept entering on this port?

see also.;msg603177#msg603177

You need a global rule for the port forward, as well as a listening application rule. You need to make a rule for the server host process to listen to Inbound TCP 25565, otherwise without a listening process the OS will consider it unsolicited traffic and drop the packet, i.e. the communication is handled (dropped) by Windows Operating System in your log.

Yep. I have both application rules and global rules set. I’ve even tried doing either one or the other, to no avail. A few months ago, the same set of rules had worked just fine under CIS v6, I believe.

I fixed the issue by adding an allow rule for the “Windows Operating System” running process. I didn’t even know you could assign a firewall rule for this process, but the weirdest thing is the process has PID 0, which means I am actually assigning an allow rule for the System Idle Process…?

Windows Operating System with PID 0 it is misleads and doesn’t System.
It was mentioned by the moderator at a forum.
Now quickly I can’t find.
Reply #12
Reply #1

Can you please tell me the details of the rule you created?

Hi guys,

I am an engineer of COMODO, and I have tried t to reproduce the issue, but can’t succeed. Based on reply here, I have modified the codes, please download and test it, the test patch is for win8(including ofr x64 and x86).

Below is test steps:
1)Open folder %windir%\system32\drivers, rename cmdhlp.sys to;
2)Download and unzip the attached files, copy related cmdhlp.sys to folder %windir%\system32\drivers;
3)Reboot machine, test application which encounters issue.

If you have any question, please tell me.

Rick ■■■■

[attachment deleted by admin]


I spent most of today fighting with this exact issue, and absolutely nothing I tried except for your patch worked. I can’t thank you enough for saving me from the frustration of trying to fix this.