captive portal new dns servers after signin
-
@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.
-
@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
-
@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). -
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?
-
@stephenw10 And that was it............
Now Google DNS returns the internal address and off to the races...
Thank you everyone!!
-
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 -
@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??
-
Yup having public DNS return private IPs is generally frowned upon. But it sure makes things easier in some situations!
-
@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. -
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".
-
What exactly are you trying to achieve?
-
@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. -
@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. -
@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.
-
So put the host override in whatever DNS server you are using.
