captive portal new dns servers after signin

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.

slu

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

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

The cert is clear to me, but host override means using the pfSense DNS server, I don't like to do that.

stephenw10

So put the host override in whatever DNS server you are using.