captive portal new dns servers after signin

michmoor

@stephenw10 said in captive portal new dns servers after signin:

he captive portal doesn't require using pfSense for DNS.

i thought clients needed pfsense for dns in order to resolve the captive portal page configured which in my case is https://portal.example.com
How would clients log in?

stephenw10

Any http request is redirected to the login page. Any recent OS detects that and shows you an alert that you need to login.

If you have a custom login page that has components that are not resolvable that could make things more difficult.

michmoor

@stephenw10
Just so im clear i can have HTTPs redirects to the portal but clients use an external DNS?
How would clients know how to resolve the portal?

stephenw10

No, not if that server is not resolvable publicly.

michmoor

@stephenw10
So as a test on a dev system i made the following change

Made portal.example.com dns name available over the internet - through cloudflare. So now if there is a dns query to the portal name it resolves to cloudflare and utlimately makes it to the firewall.

pfsense is running HA proxy on the WAN so it should receive those requests over the internet. Doesnt seem to be working.
The backend configuration i have the backend being pfsense so the IP is 192.168.11.1. This is the same IP i used when resolving portal.example.com internally for captive portal

This is the part where i am confused. When a client connects to the wifi and gets a DHCP address, does the captive portal configuration tell the client to go to https://portal.example.com? If so this works without issue when using internal DNS. External DNS is failing.

stephenw10

Is that actually resolving to the internal IP as expected? From a client before it has logged in?

michmoor

@stephenw10
If i go under DHCP Services for the interface and set the DNS server as pfsense - 192.168.11.1 - everything works fine. The portal page comes up.

If i go under DHCP Services for the interface and set the DNS server as 8.8.8.8 - portal page doesnt come up. I made the domain, portal.example.com, available over the Internet.

Typically how things would work for an external service is that I configure the HA Proxy Front/Back ends. But in this case the Front and Backend would be the firewall itself. Not sure how to get around this if this is the way to do it.

michmoor

@Gertjan said in captive portal new dns servers after signin:

I've tried my proposition above. It worked.

Ok so i tried the following just now.

On the Allowed IP lists i hadd the Google DNS server, 8.8.8.8 and 8.8.4.4
Updated DHCP server for Guest to use both Google DNS server
portal.example.com resolves over the internet. I see my test guest client query portal.example.com and gets the response of cloudflare IPs back as expected.
The guest client is not prompted for authentication and cannot access internet.

I do have HA Proxy on the WAN side so it listens on port 443. Should that matter? Does that matter? Not sure where to go from here.

stephenw10

@michmoor said in captive portal new dns servers after signin:

gets the response of cloudflare IPs back as expected

That can't work unless you're also passing those IPs in the console. Those need to resolve to 192.168.11.1.

HAProxy should have nothing to do with this. The https traffic from the clients should never leave the captive portal subnet.

Steve

michmoor

@stephenw10 then thats the part where im not following here. The suggestions all seem legit but it seems my implementation is wrong.

The guest client should receive external dns servers which presumably it will get from dhcp.
But Guest clients should also log into the captive portal that's on pfsense.
Judging by the comments this seems like it can be done. But im not following how this can be done.

If i use pfsense as the DNS server - everything works just fine. portal.example.com resolves for the client. They are given a login page by pfsense and off they go.
If i give the client an DNS server, pfsense tells them to go to portal.example.com which of course will never resolve to the internal address because the clients are using an external dns server given to them by dhcp(pfsense).

stephenw10

The issue is that the cloudflare DNS servers do not resolve the FQDN to the private IP. I assume that's because your domain is using their DoS filtering stuff?

michmoor

@stephenw10 And that was it............

Now Google DNS returns the internal address and off to the races...

Thank you everyone!!

michmoor

This is for future me or another person that searches the forum.

I had to make a change in Unbound because Cloudflare was sending a DNS Response of a private IP address when it received a query to portal.example.com - 192.168.11.1

server:
private-domain: example.com

johnpoz

@michmoor while this is one way to skin the cat.. Putting rfc1918 ip addresses in public dns is not an optimal solution..

So I understand you wants here... So its ok for some captive portal user to resolve say portal.example..com to 192.168.11.1, but you don't want them resolving other.example.com to say 192.168.11.2 ? Or otherthing.example.com to 192.168.11.3 ?

Why is that a problem? If you don't want them to access otherthing or other on example.com this is a simple firewall rule. So why is it ok for the whole planet to resolve portal.example.com to 192.168.11.1, but not some captive portal user to resolve otherthing.example.com to 192.168.11.3??

stephenw10

Yup having public DNS return private IPs is generally frowned upon. But it sure makes things easier in some situations!

michmoor

@johnpoz
No resolution to internal domains. Additionally, there is .tld filtering taking place that CP users should be exempt from.
So yes, a simple firewall rule denying anything to RFC1918 would fix any and all issues, they shouldn't be able to resolve any internal domain regardless and dont want to filter CP dns queries. Plus its about control. Whatever internal LAN service i choose to make available through CP i can do so through DNS within cloudflare. Otherwise users would have no way to resolve those internal services.

slu

This is a very interesting topic, in our case we don't want block anything over pfBlockerNG/Unbound for the guests.

Not sure how to managed this since privat ip over public DNS servers is "not ok".

stephenw10

What exactly are you trying to achieve?

slu

@stephenw10
push 8.8.8.8 to the guests, no problem with DHCP.
Before I found this topic I thought CP guests must use the local DNS server of pfSense.

In the next step we like to switch over to https but my CP is on a local IP.
Dirty path add subdomain (portal.example.com) with local ip to resolve this FQDN over google, but technically not fine.

Gertjan

@slu said in captive portal new dns servers after signin:

In the next step we like to switch over to https but my CP is on a local IP
https - some high level protocol - doesn't care what IP is used, in some low level protocol.

My captive portal uses 192.168.2.1/24 for years now, and I'm using https since day 1.
In the early stages, I got a certificate from starttls (?) but they went KO.
Then Letsencrypt came along, the acme pfsense package was made and since then I never looked back : zero mainetance.

But, there is a but. You need to 'rent' a domain name. A simple this-is-my-captive-portal.tld will do.
Ideally, you shouldn't use it on the Internet, but as your local pfSense domain network :

and from there on, with the acme pfSense package, ask for a wild card, and use the certicate for your pfSense GUI https avec, and your portal https access :

Don't forget to place a Host Override (resolver, at the bottom of the page) :

and your good. https captive portal access done.

Tip : when chose your Registrar, the place where you rent your domain names, check if they have are "acme Letsencrypt dnsapi" compliant.

edit : so yes, the https access for my captive portal costs money. A couple of $ a year [ ].
Nice side effect is : https pfSense GUI access (if you asked for a wild card cert).

edit 2 :

Forgot why I wanted to add something here.
We had a client last week, with an older with laptop Windows 10.
He couldn't use our the captive portal. Connecting to the wifi didn't show some system notification. When a browser, any browser, was opened, no messages no hints nothing.
Just a complaint on the screen : "No Internet".

I looked at his system settings (started ncpa.cpl - still works, even under 11) and there I saw this :

I explained him that that "1.1.1.1" isn't a default setting.
"Some one put it there". He didn't know what DNS or 1.1.1.1 was or means.

Still, this was a bit strange, as I have a NAT rule on my captive portal firewall that redirect "non portal interface" port 53 UDP and TCP traffic (== DNS traffic) to pfSense 127.0.0.1.
That should have 'saved' him.
But it didn't, the portal login message wasn't shown.