Another LAN DNS resolution difficulty thread
-
SOLVED!!! See the last post for details.
In a few words:
On my new (and completely awesome) SG-1100, I went through the setup multiple times and could never get DNS resolution on my LAN clients.My Setup:
I have a cable modem, which connects directly to the SG-1100, and that feeds an unmanaged switch that I use to wire up to ethernet drops in each room of my house. As far as setups go, it's really simple. The SG-1100 has an IP address of 192.168.0.1, and it hands out addresses between 0.10 and 0.240. I am using the unbound dns server. I get the same results if I select ALL for the DNS interfaces, or if I restrict them to WAN (IPv4 and IPv6) and localhost to handle lookups, and also for either ALL or LAN for incoming requests. I have tried both with the selections for registering leases and static IPs in the server, and without those setting checked, since I have read about the frequent unbound restarts when client leases are registered with the DNS server.Problem Details:
Clients have no problem getting DHCP leases and the clients get the SG-1100's LAN IP for a DNS server, but named resources (e.g., www.google.com) will not resolve from clients. It will readily resolve from the diagnostics in pfSense, and I can ping internet IPs from client machines, but names are simply not resolving. So, there is resolution at the SG-1100, and there is internet connectivity on the LAN via NAT, so the setup is this close ---> <--- to working!What I have tried:
In order to make it resolve, I can enter DNS servers (8.8.8.8 and 8.8.4.4) in the DHCP settings and have them sent to the clients when they are renewing a lease. I have seen many threads on this forum and I have tried everything that anyone has suggested, to no avail other than by pushing google's DNS servers to the LAN clients via DHCP. I have reset to factory settings multiple times, and gone through the setup, just to ensure that I haven't missed anything. I have accepted all of the defaults because I do not need more than the basic setup, presently.If anyone wishes, I can tell you what I have for any of my particular settings that I haven't already described here, but what I have (other than changing the LAN subnet to 192.168.0.0/16, everything has the defaults selected.
Does anyone have any idea what my problem might be? I haven't looked at the unbound logs (yet), and I probably should, but if there is anything obvious that I am missing, please let me know. And thank you for reading my long post.
-
On the client, does ipconfig /all show the correct IP for pfSense?
If you run nslookup www.google.com, what is the output?
Do you have any firewall rules on LAN, or is there only the default Allow All to Any rule?
-
I'm not on windows but this is the info you were asking for:
route -n get default route to: default destination: default mask: default gateway: 192.168.0.1 interface: en0 flags: <UP,GATEWAY,DONE,STATIC,PRCLONING> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0So, nslookup would not show anything before I started pushing the google DNS server IPs to clients.
And, yes, I only have the default allow all to any from lan rule, so I've added nothing else.
-
I don't see any DNS servers listed in that output.
What type of system are your clients? Looks like Linux but I'm not sure. Do you get anything by running dhclient en0?
Nslookup has to have some kind of output. I've never seen it silently fail.
Do you have a /var/lib/dhcp/dhclient.leases file, and if so what's in it?
-
DNS servers wouldn't be listed in that particular output. That's just showing default route info. To show dns servers, you have to
cat /etc/resolv.conf. When I runnslookupfor a name, I just get asterisks.The odd thing, right now, is that I'm accessing things through my wireless router, and I only have 192.168.0.1 in
/etc/resolv.conf. So I might not need help anymore!
-
False alarm. I still need the google DNS server IPs pushed to DHCP clients.
-
DNS server settings are:
- Enable DNS server
- Respond to SSL/TLS requests
- Network Interfaces: LAN, LAN (IPv6), localhost
- Outgoing Interfaces: WAN, WAN (IPv6), localhost
- Enable DNSSEC support
DNS Server settings under "General" are:
- DNS Server IPs are 8.8.8.8 and 8.8.4.4 with gateway set to "none" for both
- Allow DNS server list to be overwritten by DHCP on WAN
-
I restarted unbound, and here's what the log says, although I'll need help in figuring out what to do:
-
I thought resolv.conf only held static entries? If your clients are DHCP then dhclient.leases is usually where to look. I asked about that but you didn't address it.
Allow DNS server list to be overwritten by DHCP on WAN - you probably don't want this. If your WAN is also DHCP then your specified DNS will be replaced by your ISP DNS.
Those Unbound 'can't bind socket' errors look like you already have something listening on that address. You aren't also running DNS Forwarder or BIND, are you?
-
Hi @steve973
I think you need to decide first whether you want to use Unbound as a DNS resolver or just as a DNS forwarder. The setup slightly different for each:
A. Use Unbound as a DNS Resolver
- Make sure no additional DNS servers are entered under System --> General Setup
- Uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN" in General Setup
- Under Services --> DNS Resolver make sure DNSSEC is enabled, and "Enable Forwarding Mode" is disabled
- No need to check "Respond to incoming SSL/TLS queries from local clients" unless you actually have your clients setup to send DNS requests over SSL/TLS
- No need to select IPV6 under network interfaces unless you are actually using it on your LAN/WAN
- Make sure that under Services --> DHCP Server you are not overriding the DNS server settings manually.
- Make sure your clients are setup to obtain DNS server information as part of the DHCP request (i.e you are not manually overriding it in resolv.conf, etc.).
B. Use Unbound as a DNS Forwarder:
- Enter DNS servers you wish to use under System --> General Setup if you want to use DNS servers other than your ISP's. If you want to just the servers you entered (e.g. 8.8.8.8/8.8.4.4) be sure to uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN" in General Setup so that your ISP's DNS servers are ignored.
- If do you wish to use your ISP's DNS servers, make sure that "Allow DNS server list to be overridden by DHCP/PPP on WAN" in General Setup is checked.
- Under Services --> DNS Resolver make sure "Enable Forwarding Mode" is enabled.
Steps - Steps 4 - 7 from above remain the same.
Hope this helps.
-
For the people that participated in this thread to help me out, thank you very much for helping. I figured out the problem today. I have a tp-link archer c9 wireless router that was conflicting with the IP address of the netgate appliance. DNS queries were being intercepted by the wireless router, so when I was trying to use the recommended settings through pfsense and provide the appliance's lan address as the DHCP server, it was actually using the wireless router's DNS. So I have that fixed, and now everything is working perfectly!
For anyone who comes across this thread in the future, if you are having issues with DNS, and nothing seems to be working, then try removing your wireless router from the network and shut it down. If that fixes the problem, then you have a collision with your wireless router like I had.
-
To server as an explanation to the people who helped me, and for better information for anyone who comes through here with the same problem, here is some more information about exactly what was wrong:
- I have pfsense set up statically as 192.168.0.1 on the LAN port. Through DHCP, it serves up addresses in the 192.168.0.10 - 192.168.0.240 range.
- I have my tp-link router on the network, and it obtains an address via DHCP from the pfsense appliance. It was getting 192.168.0.11 at this time
- I had the LAN interface on the tp-link router set statically to 192.168.0.1. I am not sure why or how this was the case, since it worked with my old pfsense setup.
- Oddly enough, because these networks were separated through the tp-link router, there was not an actual conflict between the pfsense appliance and the wireless router.
- The pfsense appliance was providing DNS resolution, and the tp-link router was handing out 192.168.0.1 as the DNS server.
- For clients connecting via ethernet or wireless through the tp-link router, this was the IP of the tp-link router which does not provide DNS resolution.
Thus, DNS on the tp-link router's network would fail because the tp-link router did not route the DNS requests to the netgate appliance. Having the same IP address, even on different logical networks, prevented this. I am not sure if I could have set up a route that might have made this work, but it seems like a bad setup anyway.
I have moved the tp-link router to the 192.168.1.0 subnet, and it hands out addresses, via its DHCP server, in this subnet. Now 192.168.0.1 is unambiguous, and DHCP requests now route correctly.
-
Your tp-link should just be used an an AP - the router mode should b deactivated.
Give it a static IP like 192.168.0.2.
Shut down DNS shut down DHCP server and client.
If it has a RJ45 plug called WAN on it's back, don't use that one. Use a (the) LAN plug.
-
@gertjan I don't necessarily agree, although your suggestion is reasonable for some use cases. There are many, many levels of NAT throughout the interconnected networks on the internet, and adding another level of NAT in my home is not a problem in and of itself. In fact, with the right routing table, the problem that I had would not have been a problem.
