Internal DNS not resolving
Captive Portal on pfsense 2.1
I am using dhcp relay on the lan interface and pointing to a Windows DHCP server which lives on a different subnet
I get ip addresses and I can browse the web no problem using Captive Portal, transparent Squid, Windows Radius. However, I cannot resolve internal names, for example our website, servers by name etc. It is just the internal stuff. If I ping an internal dns address it doesn't find it. I can ping external websites, bbc, gogole etc.
update: I hope this can shed some light
I had my Windows DHCP server dishing out ip address to my wifi users that were connecting to CP but I had set the DNS option to point to the pfsense box. I'll expand
Wifi users get their IP address from a scope on the Windows server (DHCP relay on pfsesne) with pfsense as the router and the DNS server (set in scope options).
I took out the DNS scope options that was telling clients to use pfsense for DNS for the wifi subnet. This resulted in my DNS servers from AD being propogated into the scope options.
Now my clients get their IP address from the Windows DHCP and also get the DNS addresses of Active Directory servers and pfsesne as the router.
When I open up a web page (http://www.google.co.uk), I am now not getting the Captive Portal page. However, if I type the IP address of Google, I get the Captive Portal page and then after logging in I can browse the web as normal and resolve my internal DNS issues from my original post.
What am I missing here, I cannot seem to hit CP with DNS name of websites to begin with but after authenticating via browsing the a websites IP address DNS works fine.
google likes to redirect to https. I think some of the browsers and browser plugins (https everywhere) like to do that behind the scenes for you, which would break CP. I have found it's hit and miss using google as your target pre-captive portal login, unfortunately, because, fortunately, they are making more and more services https by default.
Not being able to ping does not mean name resolution is broken. Resolving names does not mean you can ping. It's four steps:
Resolve the name
Use a web browser to connect to that IP (obtained from DNS) http on port 80
Authenticate through the captive portal
ICMP through to the destination and back.
Need to know which ones are failing.
Google was just an example. I was trying other non https sites too. Its as if DNS will only work after I have authenticated. I'll report back tomorrow with an update and confirm.
It doesn't matter where the DHCP server is as long as the clients are getting good settings from it. Once the client has DNS servers from the DHCP server, the DHCP server is out of the picture.
Before authenticating through the CP, check what the client was given as DNS servers from DHCP.
dig @ip.of.dns.server1 fqdn_to_resolve
dig @ip.of.dns.server2 fqdn_to_resolve
repeat for all name servers. They should all give sane A records.
If you don't get an A or CNAME record but get a response it'll probably be either NXDOMAIN (that name server thinks the fqdn doesn't exist) or SERVFAIL (basically means the server could not complete the query for some reason, such as being listed as a master NS for a zone and not having that zone configured.)
If you don't have dig (sorry), you'll have to do the same with nslookup. Probably something like "nslookup fqdn_to_resolve ip.of.dns.server1"
If any of them timeout, be sure they're in the CP's allowed IP addresses AND are passed by the firewall rules of the interface(s) on which the CP is listening.
You should be able to bring up the captive portal page with http://ip_address_of_server_returned_by_dns_server:80/
Bottom line is don't use ping, etc to debug DNS resolution issues. Use a DNS tool such as dig.
Hi Derelict, as you pointed out with
" be sure they're in the CP's allowed IP addresses AND are passed by the firewall rules of the interface(s) on which the CP is listening."
I put my DNS server in the 'Allowed IP addresses' on CP. I could then try to access a site such as http://www.google.co.uk and this resulted in me being sent to the CP page which is exactly what I wanted.
So by setting the DNS servers in the allowed list, it lets my clients resolve DNS without having to log in first. This may be standard practice but I was unaware until you pointed it out.
I am now off to block ports such as telnet etc as I want to restrict wifi users to only http traffic. That will be on another topic no doubt.
The allowed IP address requirement only comes into play for basic CP functionality if the DNS server the client is instructed to use is not on the client's local subnet, including the pfSense LAN port/DNS forwarder.
You will therefore see many cases where it's not necessary.
It, along with allowed hostnames, is also useful in configuring a "walled garden" which allows access to certain web assets without going through the portal first. It also allows you to use outside assets to make up the portal page itself.
Glad it's working.