Is Captive Portal supposed to leak connections?

[GeoffW]

(Edited to say this was my mistake, see my later post https://forum.opnsense.org/index.php?topic=31769.msg154049#msg154049.)

I notice that devices that have not yet logged in to the Captive Portal - and do not have an exception listed - are still making some connections to the Internet.  I did not expect this.  ( I don't recall it happening on the pfSense firewall I was running up to now - but I guess it's possible it happened without me noticing it. )

I can confirm the connections on the device (eg: a Windows 10 VM running TinyWall lets me see the established connections), but it was ZenArmor showing the sessions that first brought it to my attention.

For example, when I start Firefox on a Windows 10 VM it brings up the expected "You must log in to the network before you can access the Internet".  Meanwhile, in the background the Internet is already being accessed.  At the very least "detectportal.firefox.com" and "safebrowsing.googleapis.com" are getting through, but I also use a speed-dial set up and it seems that at least some of those are updating too.

With Vivaldi (a Chromium based browser) I see much the same thing, with connections to "update.vivaldi.com" and "update.googleapis.com" amongst others.


Is this supposed to happen, or is this a bug in 22.7 that I should be reporting?

[franco]

Have you confirmed this with a packet capture? They should all be given the same login page until logged in.


Cheers,
Franco

[GeoffW]

So I have a Windows 10 VM.  It does not have an exception in Captive Portal and is not currently logged in.

I start a packet capture on the LAN interface, specifying that VM's IP address and port 443 (most of these connections appear to be happening on 443).

Then I start Firefox and I get the little bar at the top asking me to log in to the network, but I ignore it.  I wait a few seconds (during which I look at the TinyWall "connections" display and see a number of Internet connections showing as "Established").  Then I close Firefox.

Here is a small sample from the start of that process showing requests going out from 10.xxx.yyy.151 and responses coming back from 34.117.237.239 (Google apparently).

Code Select Expand

11:55:28.109210    ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 5544, offset 0, flags [DF], proto TCP (6), length 52)
    10.xxx.yyy.151.55784 > 34.117.237.239.443: Flags [S], cksum 0x30c9 (correct), seq 3417154090, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:55:28.109275    ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    34.117.237.239.443 > 10.xxx.yyy.151.55784: Flags [S.], cksum 0x8a81 (correct), seq 4183075335, ack 3417154091, win 65228, options [mss 1460,nop,wscale 7,sackOK,eol], length 0
11:55:28.109576    ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 5545, offset 0, flags [DF], proto TCP (6), length 40)
    10.xxx.yyy.151.55784 > 34.117.237.239.443: Flags [.], cksum 0xa90b (correct), seq 1, ack 1, win 8212, length 0
11:55:28.110918    ethertype IPv4 (0x0800), length 571: (tos 0x0, ttl 128, id 5546, offset 0, flags [DF], proto TCP (6), length 557)
    10.xxx.yyy.151.55784 > 34.117.237.239.443: Flags [P.], cksum 0x68e3 (correct), seq 1:518, ack 1, win 8212, length 517
11:55:28.110958    ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    34.117.237.239.443 > 10.xxx.yyy.151.55784: Flags [.], cksum 0xc51c (correct), seq 1, ack 518, win 510, length 0
11:55:28.112754    ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    34.117.237.239.443 > 10.xxx.yyy.151.55784: Flags [.], cksum 0xf5c3 (correct), seq 1:1461, ack 518, win 514, length 1460
11:55:28.112782    ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 1500)
    34.117.237.239.443 > 10.xxx.yyy.151.55784: Flags [.], cksum 0x6ea4 (correct), seq 1461:2921, ack 518, win 514, length 1460
11:55:28.112800    ethertype IPv4 (0x0800), length 675: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 661)
    34.117.237.239.443 > 10.xxx.yyy.151.55784: Flags [P.], cksum 0x5a89 (correct), seq 2921:3542, ack 518, win 514, length 621

Certainly looks like a conversation happening to me.

If I put an actual Firewall rule in to block 10.xxx.yyy.151 then Firefox never displays the bar prompting me to log in to he network and the TinyWall connections display shows Firefox attempting to make connections but the state never gets past "SynSent".

Much the same sort of thing happens when I use Vivaldi (Chromium).

I saw something similar on a system running an Apache server, where it made some Internet connections despite that host being blocked by Captive Portal.  But I am having trouble replicating this.

Presumably what is getting through is deliberate.  The fact that the login prompts never appear if the device is completely blocked even suggests that some of the connections are necessary, but it wasn't what I expected ... and I'd be interested to know what the rules are: what is allowed through without authorisation?

[cookiemonster]

Just a guess, as I had to look for something to do with messages from firefox in my work laptop when working from home. I do not use captive portal in OPN.
In firefox in about:config the value pair for network.captive-portal-service.enabled I had to set it to false to stop the messages. I'm wondering if you do the same, will the traffic stop?
It doesn't answer the imho good question that it should stop all, but maybe could help you narrow down the symptoms.

[GeoffW]

Thanks for the input, I had not thought to look in the client app config.  Turning the captive portal Enabled option to false prevents that button bar from popping up asking to log in to the network, and I think means there are one (or maybe a few) less Internet connections established before log in, but there are still some connections established.

[GeoffW]

This turns out to be my mistake/misunderstanding.  :-[   (Surprise, surprise, surprise.  ;))

After much research, including reading some docs from pfSense, which cover packet capture in more detail (like where it actually happens) than the OPNsense docs, I now know more than I did.

Yes, while ever I'm looking at the LAN interface it looks like there are active connections. (And looking at the LAN interface is what ZenArmor is looking at in my set up; what I used for my previous packet capture; and what I see when look at connections in the VM.)  But apparently these connections are lies told by Captive Portal: it is spoofing the connections to try and make redirections happen smoothly in the browser.

I thought I'd seen corresponding traffic on the WAN interface but probably saw something resulting from other hosts on the network.  Tonight, while the network was quiet, I captured LAN and WAN simultaneously and then stepped through the results in WireShark and was able to verify that none of the Internet hosts that are reported on the LAN side as having connections when starting Firefox or Vivaldi actually appear on the WAN side at all.  If there are more connections now than what I've noticed before, it could be because things changed on the browser (certainly Firefox seems to have something more elaborate going on than the last time I used it).

So my apologies to anyone whose time I have wasted.

Tracking things across the NAT is where I always stumble.  I've yet to find a tool that makes this easy/obvious.

[cookiemonster]

glad is now clearer. Thanks for posting back.