captive portal new dns servers after signin
-
@michmoor why do you not want them using pfsense for dns? If you don't want them resolving local resources, you can just create a view so they can not.
-
@johnpoz create a view…good idea. And that’s exactly it I don’t want them resolving any local resources regardless if there is a firewall rule rejecting that
edit: the problem with the view is that there are resources in the example.com space that are accessible over the internet and over intranet. How does a view help?
-
@michmoor A view allows you to resolve specific things from your local resources.
-
@michmoor said in captive portal new dns servers after signin:
Any idea?
Yep, one.
Add the IP of "another DNS" in the Allowed IP addresses list, for example 8.8.8.8
Add this IP to the DNS list on the captive portal DHCP server :
Done.
Works for me -
@Gertjan but sounds like he need to resolve "some" local stuff.
-
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.
-
@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.
-
@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? -
Is there some they can't just use public servers all the time? The captive portal doesn't require using pfSense for DNS.
-
@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? -
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.
-
@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? -
No, not if that server is not resolvable publicly.
-
@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 portalThis 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.
-
Is that actually resolving to the internal IP as expected? From a client before it has logged in?
-
@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.
-
@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?