Captive Portal checks

[Marc05]

I've noticed Portmaster makes some requests on startup to captiveportal.local.portmaster.home.arpa which it (Portmaster itself, not upstream DNS servers) resolves to 192.0.2.1 and then tries to establish a TCP session - I presume it's to check if it's behind a Captive Portal.

I wouldn't necessarily call this a bug, but I couldn't find any reference to this behavior in the docs nor the source (other than this), so I'm not sure what to make of it. Ideally this could be turned off by the user via some advanced option.

[Raphty]

Thanks for the notice, we are moving the docs to the wiki, and I hope I will not forget to add this.
if I do, feel free to point out that you have found it first and pointed it out in the past.

[LoganDark]

it (Portmaster itself, not upstream DNS servers) resolves

This does look like a bug, isn't the captive portal request supposed to go to the upstream DNS servers, since that's where the captive portal is?

[dhaavi]

There is more documentation on this here: https://docs.safing.io/portmaster/architecture/core-service/secure-dns/

Why would want to turn this off?

The Internet standard states that both .home.arpa domains and the IP 192.0.2.1 and may not be routed on the Internet. So this information will not be leaked by any standards following system.

@LoganDark: The captive portal is always in the local network, so sending this request to a resolver on the Internet will never lead to a result. The test requests are to be intercepted by a local captive portal in order to check if a local portal exists at all.

[LoganDark]

sending this request to a resolver on the Internet will never lead to a result

Yes it will. Captive portals intercept these requests, that's their entire job.

The test requests are to be intercepted by a local captive portal in order to check if a local portal exists at all.

So why does Portmaster intercept them itself and never send them to the network, local or not?

Portmaster asks if there is a captive portal and then answers itself automatically with "of course not".

[Marc05]

There's no reason why Portmaster itself should be resolving the query to 192.0.2.1 and sending a request to the address. The reasoning given here was that it's a documentation-only address space and it shouldn't be used anywhere (which is a silly argument to make on software that's supposed to allow the user to control network access). Yet, Portmaster itself is using it which is contradictory.

Portmaster does a great job of simplifying something that only advanced users would deal with. These networking quirks simply get in the way of these users without providing any real benefit.

The Internet standard states that both .home.arpa domains and the IP 192.0.2.1 and may not be routed on the Internet. So this information will not be leaked by any standards following system.

These are used in labs/intranets/etc.

Why would want to turn this off?

Because as Portmaster itself has shown, these test-net/documentation networks are legitimately used in practice. The behavior now is needless and can break user's networks.

Yes it will. Captive portals intercept these requests, that's their entire job.

Captive Portals are local, hence these requests shouldn't be reaching the internet. If Portmaster wants to intercept DNS queries to .portmaster.home.arpa, that's fine by me. The issue is the seemingly hardcoded address that it responds with - why does Portmaster assume a Captive Portal will always be at 192.0.2.1?

[LoganDark]

Captive Portals are local, hence these requests shouldn't be reaching the internet.

I think you misunderstood what I said. Captive portals redirect DNS requests to the captive portal. Therefore the only way to discover the existence of the captive portal is to actually make a DNS request to the network. But Portmaster never sends anything to the network - it sends a DNS request and then intercepts itself, answering itself, without ever actually reaching the network, so it will never actually find the captive portal, will it?

Unless your issue is talking about something else.

[Marc05]

I see, that's mostly correct. It would find the Captive Portal if it's at that address :)

[github-actions]

This issue has been automatically marked as inactive because it has not had activity in the past two months.

If no further activity occurs, this issue will be automatically closed in one week in order to increase our focus on active topics.

[Marc05]

This is still an issue.

[Raphty]

obviously there is almost no interest in this, and as @dhaavi referenced in the past there is documentation. If you have something new to add I can reopen this "issue"