COMODO Firewall 10 does not block IPv6 connections. [M2240]

I have COMODO Firewall
I just found that the firewall does not block IPv6 connections.

I tested this on my web browser (Firefox). I first created an application rule in CFW to block a single IPv4 address for Firefox. It worked, the browser could not connect to that address. Then I modified that rule to block a single IPv6 address. This did not work. The browser still could connect to the IPv6 address.

The same happens when I create a global rule for IPv4 and IPv6 addresses.

When I create an application rule to block all connections for the Firefox, the browser can not connect to IPv4 addresses, but it still can connect to IPv6 addresses.

Could anybody check this and see if this is a bug, or if I just have wrong settings somewhere?

This link may help you. Why IPv6 filtering default disabled?

Thanks for the link. I have the “IPv6 filtering” enabled.
I am confused about the global rules: why should I allow ICMPv6, if I instead want to block IPv6?
Also, if this is a bug, as suggested in that thread, then this is a security vulnerability.
Most people just install a firewall and think they are protected, while in fact they are quite open to threats.

I have these global rules set by default:

Do I really need to change all of them in order for the IPv6 filtering to work?
Would it not open other vulnerabilities?

By the way, did anybody have a chance to confirm this on CFW 10?

Those rules referenced in that thread is only needed if you set the firewall to stealth ports mode from the stealth ports firewall task. But you’re using alert incoming connections as seen by your global rules screenhot. You shouldn’t even be allowed to connect over IPv6 with that block ICMPv6 rule, so IPv6 filtering is clearly broken. To even confirm it, use the stealth ports task and set it to block incoming connections, then go to this site Online IPv6 Port Scanner and Firewall Tester to check to see if any of your ports are accessible.

Do you have another computer on your LAN that you can try to test link-local ipv6 blocking with? I can block link-local but I can’t test public IPv6 connectivity as my ISP does not offer native IPv6. I’m assuming yours does and you are using a dual-stack setup. Finally you try to block the ping.exe command by adding it the firewall application rules as a blocked application ruleset and then issue ping -6 to see if you get replies or not.

What OS are you using? Would you be willing to try this build to see if you still can reproduce the issue?

Thank you for the help, futuretech.

I have Windows 7 Home Basic SP1 on my computer.

As to trying the beta build, I do not feel like I am up to that: too much hassle, very high chances that my computer becomes dysfunctional and/or the security becomes breached. I already had a lot of troubles updating to the current build. So if I am to update again I would rather wait for a stable build where all the issues are resolved.

Also, I do not have any other computers in the network that I can access.

As you suggested, in the Stealth Ports task I chose “Block all incoming connections”, then I went to Online IPv6 Port Scanner and Firewall Tester, but the web page said:
“The request for this page was made using an IPv4 address and so your machine cannot be tested. Your machine may have accessed this page using IPv4 if your DNS configuration is broken or your browser or DNS service does not correctly prioritise IPv6.”

I also have tried another site:, below are the test results:

They do not make much sense to me.

Now things are getting weirder and weirder.
Today in my Network Connection properties I turned off TCP/IPv6.
But I still observe IPv6 connections.

All the following is done with IPv6 disabled in the Network Connection properties window.

The command ping -6 works, albeit the round trip times are rather high.
The IP address is 2a00:1450:4010:c0a::65, and it changes from time to time.

In COMODO Firewall I created a firewall rule for ping.exe to block a single IPv6 address 2a00:1450:4010:c0a::65:

Now, when I type in the Command Prompt ping 2a00:1450:4010:c0a::65 the connection is blocked, no packets are received.
In the Firewall Events Log I see the corresponding event of blocked ping.exe connection.
When I create the same firewall rule for Firefox browser

Firefox still can connect to this IPv6 address

When I make a firewall rule to block all connections for ping.exe, then ping can not connect to any IP,
and neither ping nor ping -6 work.
The blocking of both of these connections is recorded in the Firewall Events Log.

When I make the same firewall rule for Firefox to block all connections, then Firefox becomes unable to connect to any IPv4 address, but it still can connect to IPv6 addresses. And in the Firewall Events Log only the blocking of IPv4 connections is recorded, while the IPv6 connections do not show at all.

When I make a global rule to block all connections for all programs, then neither ping nor firefox can connect to the Internet.
But in the Firewall Events Log only blocking of IPv4 connections is recorded.

When I make a global rule to block a single IPv6 address 2a00:1450:4010:c0a::65,

then ping.exe can not connect to that IP, and the blocking is recorded in the Firewall Events Log.
But Firefox still can connect to that IP and no records appear in the Firewall Events Log.

So, the conclusion for now is: the IPv6 blocking works for some programs, like ping.exe, but it does not work for programs like firefox.exe and cmdagent.exe. The latter two, I believe, belong to the group of “safe applications”.
Also, ping.exe connects through ICMPv6, while firefox and cmdagent through TCP.

Does this make any sense to you?
Also, why is the IPv6 connectivity fully functional on my computer, even though I disabled it in the Network Connection properties?

Everything is working as it should be as you do not have native ipv6 connectivity as I incorrectly assumed. You have 6to4 which means ipv6 is encapsulated inside an ipv4 packet. To block such connections, create a block outgoing global rule where protocol is IP and under IP details tab select custom and enter 41 in the box. Also if you had set the application rule for firefox to be treated as a blocked application you would see that you can’t access any site over ipv4 or ipv6.

Also unchecking ipv6 in the network adapter properties does not disable ipv6 entirely, you would need to disable it via the registry see this Microsoft help.

Thanks for the help, futuretech.
The global rule worked. Now, at last, I do not see any traffic form cmdagent.exe.
Wish it were easier.
I have a few more questions:

  1. Is there any way to make such a rule not global but per application?
  2. Why when I made a global rule to block a singe IPv6, that rule worked for ping, but did not work for firefox?
  3. Where can I find documentation on how to make custom IP rules and what numbers correspond to what?

You can try to make that rule in the applications rule to see if it works.

2) Why when I made a global rule to block a singe IPv6, that rule worked for ping, but did not work for firefox?
I'm not sure, it could be that it was sent out via the [url=]teredo[/url] interface which is a different tunneling method. You can test by looking in the logs to see what the source address is and compare it to the output of the ipconfig command.
3) Where can I find documentation on how to make custom IP rules and what numbers correspond to what?

What astounds me though is that this is a security vulnerability that COMODO was aware of. That is why they used it in their cmdagent, to prevent people from blocking traffic from that process. And now that there is a law in the US, which allows companies to sell data that they acquired from their customers, I assume there might be a commercial interest in that. So, COMODO intentionally left a loophole in the firewall, which they were exploiting by themselves, but they did not inform the public about such a loophole, nor did they care to make a clear and easy way to close it. Apparently, such a vulnerability can be exploited by a malicious actor. So, COMODO only creates an appearance of security, while in fact they leave loopholes in their customers’ systems. I wonder how many more security holes they have intentionally left that we are not aware of.

Unfortunately, this method does not work when I try to make an application rule.

I'm not sure, it could be that it was sent out via the [url=]teredo[/url] interface which is a different tunneling method. You can test by looking in the logs to see what the source address is and compare it to the output of the ipconfig command.

ipconfig says “Teredo Tunneling Pseudo-Interface”

Is it possible to block Teredo on a per application basis?

Thanks for the links.

Yes when you run ipconfig you should look at the IPv6 address field and use that address in your block outgoing rule as the source address.

That does not work either.

Also, when I make a rule to log all connections from Firefox, and then I navigate to http://[2a00:1450:4010:c0a::65]/, this connection is detected by TcpLogView, but it is not detected by COMODO firewall. In the firewall log there is no connection from IPv6 address, or to IPv6 address, or where protocol is IPv6.

When I make a global rule to log all IPv6 connections, and then in the Firefox I navigate to the above address, in the firewall log I see a connection from SYSTEM where protocol is IPv6, but the source and destination addresses are both IPv4, the latter is, though it changes from time to time.

IP address is an IPv4 address owned by IPv6 to IPv4 relay and located in “No unique location”, ASN: 1103 - SURFNET-NL SURFnet, The Netherlands, Organization: RFC 3068.

The same happens for the cmdagent.exe.

Again, TcpLogView detects these connections as connections from the corresponding programs through TCP to the corresponding IPv6 addresses from the local IPv6 address (look for example my above posts). But COMODO does not detect them at all.

Is this a bug? Because before you said:

Can you try checking connections with tcpview and looking at the source address when you try to visit an ipv6 address with firefox then compare that source address with an ipv6 address in the ipconfig /all output. TcpLogView does a different method of identifying connections but we can check if it is really a bug using tcpview or killswitch active connections. You can get killswith by running the view connections task and clicking the more button. is an anycast address that is used for the purpose of sending packets to a 6to4 relay router. The prefix route of is used for routes pointed at 6to4 relay routers that use this anycast IP address.

I don’t think 6to4 transition can be filtered at the application layer sense that this transition happens in the windows kernel. But I’m not sure so ill see if I can get a response from a comodo staff member to clarify this issue.

I ran ipconfig /all. It appears I have three Tunnel adapters:

  1. Teredo Tunneling Pseudo-Interface

  2. Microsoft ISATAP

  3. Microsoft 6to4 #10

Only the first and the third adapters have IPv6 addresses and they are completely different.

When I use Firefox to navigate to an IPv6 address, this connection is detected by the TcpLogView, and the Local Address shown for such connection is the IPv6 address for the “Microsoft 6to4 #10” adapter.

The same is true for connections made by cmdagent.exe.

I suppose, this indicates that Teredo is not employed here.

In addition, when I ping an IPv6 address, such connection is detected by COMODO firewall (it is ICMPv6, not TCP), and in the firewall log the source IP again is the same as the IPv6 address for the “Microsoft 6to4 #10” adapter.

KillSwitch also detects connection when I navigate Firefox to an IPv6 address, the destination address is shown correctly as IPv6, the Local address is shown as that of “Microsoft 6to4 #10” adapter, also IPv6. Only the protocol is shown as TCP6, not just TCP.

But COMODO “View Connections” window does not show such connections. Instead it shows a connection from SYSTEM, protocol IPv6 OUT, from local IPv4 address to destination IPv4 (

That is interesting so it seems the firewall can not filter tcp and possibly udp traffic sent using 6to4 encapsulation at the application level, but works with icmpv6 which doesn’t get encapsulated and is sent as is. And view connections can not see ipv6 tcp/udp traffic made by applications but killswitch can, and can only see icmpv6 instead. I’ll point comodo to this thread to see if they can explain the differences. Thanks for testing.

Thanks for the help. Hopefully they could figure this out (if it is not “by design”, seeing how cmdagent conveniently switched form IPv4 to IPv6 after I set firewall to block all connections for that process.)
Let me know if you have any other ideas.

Any news on this?

Still waiting. It’s been 8 days already. COMODO does not seem to be motivated enough to address this issue.

I admittedly forgot to ask previously but have notified Umesh yesterday and he said he will check it, so you should get more info something this coming week.

I have reported the issue. Will see what they say.

Thanks :slight_smile:
Any update?