Firewall stops WiFi with captive portal from working

I’m on 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?? :frowning:

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.

Appreciate the quick reply. :azn:

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, 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?

Do I need to censor out anything before I send? (If so, how? And am I PMing these or posting them here?)

No need to censor anything as your IP and router IP address are private addresses and you can attach the results here or you can PM to me if you want.

Hmm, doesn’t look like attachments are allowed on ■■■. So, here they are.

[attachment deleted by admin]

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 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 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.

Hm, that’s very strange. Is this a common syndrome for captive portals, but not ordinary APs? (Trying to think why they would even do that…)

A bit late to try tonight, but I’ll try tomorrow and see if this “fixes” it.

Yup, that does seem to make it work. Too bad this opens an attack vector. :frowning:

What’s the story, router manufacturers? Can’t you guys make a captive portal work on the same gateway?? >:(

I recently had this problem and had nailed it down to ARP cache filtering setting by varying the Firewall settings.