I’m on 8.2.0.4674. WiFi access points that have captive portals (forced first web pages you have to acknowledge before the Internet works right) seem to be broken if I use the firewall at all. (Meaning the WiFi shows a connection, but I can never get that first page to load.) Setting it to “Disabled” is the only way to make it work. But obviously this defeats the whole purpose — public WiFi is one of the primary reasons for using a software firewall in the first place!
I’ve tried everything from reinstalling to clearing out all my rules to several other settings changes, and nothing seems to work. Also there’s nothing produced in the firewall events log during the process failing either.
Can anyone help??
I do halfway know what I’m doing, so don’t be afraid to get technical…
Whenever troubleshooting network issues, wireshark is your friend. Run a packet capture with the firewall disabled while completing the captive portal connection, then retry with the firewall enabled and you should be able to note differences when packets are being blocked. Also comodo does not have logging enabled for any of its default global block rules, so enable logging of events for any and all block rules you have listed under the firewall global rules. When connecting with the firewall enabled, do you get assigned a valid IP address? run ipconfig /all and take note of whats shown for your wireless adapter.
First I tried enabling global-rule logging; still nothing in the logs.
It does appear to get a valid IP address. DNS seems to work too, depending on the AP I connect to.
I put Wireshark on the machine and ran the captures as specified, but I’m not entirely sure what it is I’m supposed to be looking for in all this (~1000 packets in each one). I think I see TCP retransmissions for the attempt to load a page, but I’m not sure what about them might indicate what the problem is…
Ok I can take a look at the captures. Just save two separate capture files and name one with firewall-disabled and one with firewall-enabled. When doing the captures start BEFORE connecting to the AP. So do this:
1.) have wireshark capture running when disconnected from AP and make sure comodo firewall is disabled.
2.) Connect to AP. Go through captive portal process.
3.) navigate to google.com, when page loads stop and save packet capture.
Do the same steps but with comodo enabled and just wait for the page to either load or time out if it seems to take awhile, if it does try not to reload the pages or go to different websites. At anytime you cant access a page whether its the captive portal or google and it stops trying to connect, stop and save the capture. Also could you post a screenshot of your global rules and of the firewall settings pane?
Just as I suspected was the issue and it’s and easy fix but comes at a price. Whats happening is that when you are accessing the internet all request packets are being sent to one router (proxy gateway) but the return reply packets are coming from a different router (the real gateway to the internet), which can be seen by opening the firewall-disabled capture and enter tcp.stream eq 12 in the filter bar and notice the src and dst MAC addresses of packet number 285 and 286. These packets are the initial connection attempt to google.com. Azurewav_27:c1:1a is your network adapter and IETF-VRRP-VRID_99 (00:00:5e:00:01:99) is the proxy router. The real router/gateway which are sending the reply packets to your computer in the next packet frame is ArubaNet_23:29:90. In the firewall options there is a setting called ‘Enable anti-ARP spoofing’ which protects you from Layer 2 (Local Area Network) Man-in-the-Middle attacks that blocks packets coming from MAC addresses that you have not directly sent packets too.
TL:DR packets are being sent to one gateway when connecting to the internet and the reply’s are coming from a different gateway which triggers comodo firewall to block the reply packets because of “Enable anti-ARP spoofing” setting in advanced options screen. Disabling this setting regains connectivity, but won’t prevent an ARP-spoofing MitM attack targeted at you. But chances of you being targeted by such an attack is slim to none.
