captive portal new dns servers after signin

Gertjan

@johnpoz

Is there a way after a device is approved to give new DNS servers?

Without (manual) interaction on the device after portal login, I'm not sure, never heard of such a thing.

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

I would like Guets to use google or cloudflare or whatever but not pfsense for dns

I've tried my proposition above. It worked.

johnpoz

@Gertjan I would agree with you.. Just have the clients use some public dns from the get go, ie hand that out in dhcp.

But does this seem like he wants local stuff to resolve, could always use nat reflection to access it as another option if you do need to access local services.

here are resources in the example.com space that are accessible over the internet and over intranet.

michmoor

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

I would agree with you.. Just have the clients use some public dns from the get go, ie hand that out in dhcp.

Ok so question.
Have guest use captive portal. Login successfully.
Do the guest then have to manually switch to a public DNS server or is there some kind of redirection that can happen?

stephenw10

Is there some they can't just use public servers all the time? The captive portal doesn't require using pfSense for DNS.

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.