Pfsense can't resolve dns, can't find updates
-
2.1.5-release
pfsense is getting a DHCP address from my ISP and I am running my home network behind it. I am using OpenDNS' servers, and a google DNS server, for DNS. All clients behind pfsense can resolve (all IPs assigned via DHCP via pfsense). pfsense cannot resolve.
–
[2.1.5-RELEASE][root@firewall.none]/root(6): cat /etc/resolv.conf
domain none
nameserver 208.67.220.220
nameserver 208.67.222.222
nameserver 8.8.8.8
[2.1.5-RELEASE][root@firewall.none]/root(7):
–--
[2.1.5-RELEASE][root@firewall.none]/root(7): nslookup www.google.com
;; connection timed out; no servers could be reached[2.1.5-RELEASE][root@firewall.none]/root(8):
–I am now triple checking my firewall rules to make sure I am not somehow blocking pfsense from resolving dns. So far everything looks fine.
Not sure where else to look.
-
Set DNS server to only 8.8.8.8; clients can still resolve fine, pfsense can't.
-
Could it be same problem I had?
It seems that there is typo in configuration section of autoupdate!?
Autoupdate is trying to get file from address:
http://updates.pfsense.org/_updaters /latest.tgz (see there is space) but correct address is:
http://updates.pfsense.org/_updaters/latest.tgz
This can be solved with upgrade from console and copying right address but this is annoying.
-
Not sure about the update bug, but its definitely a resolving issue. I use a private VPN, and when I change servers, I have to use the IP address, not the FQDM, or pfsense breaks. I can resolve from all hosts behind the network, but cannot resolve from pfsense directly. If I enter the FQDM for the VPN server, then pfsense can't resolve, and the entire network breaks.
-
Can you ping the name servers from pfsense?
What about tracerouting to them?
Can you try these commands instead of using nslookup?
dig @8.8.8.8 www.google.com
dig @208.67.220.220 www.google.com
dig @208.67.222.222 www.google.comMy guess is there's something about the source address being used for your DNS queries sourced from pfSense that's not routable somehow.
You can set the bind address (source address) for the outgoing query like this. It has to ba an address on pfSense itself:
dig -b 192.168.1.1 @208.67.222.222 www.google.com
In the quick testing I just did, that will succeed if there is outbound NAT for 192.168.1.0/24 and fail (timeout) if not so it appears to be doing what's intended.
I couldn't quickly find a way to tell dig to report the bind address used automatically. You might be able to catch it looking at the states. Certainly if you enable a floating match rule for TCP/UDP 53 on WAN out with logging you should get the address being used in the firewall logs.
-
Wow. No, I can't even ping any DNS servers, 'no route to host'
Yet it works behind pfsense on the client machines.
-
Fixed.
No idea how it happened, but somehow in setting up the PIA VPN, the system's default gateway was set to an address on a range I don't even use. I went into the routing section, deleted said gateway, and it instantly added a DHCP-based gateway with an address on my ISP's range. Now everything works. Unfortunately, the world sees me as on my ISP, not on the VPN server from my VPN service company.
Hmmm….
-
If you set the gateways on your DNS servers to the proper ISP, your DNS servers should get /32 routes out that specific gateway which should override the default route out the tunnel.
Note that this leaks your DNS queries to the global internet and they will no longer go out PIA (if your clients are configured to use them) so you're leaking info if you want to stay anonymous.
Otherwise you need to figure out how to use PIAs name servers, or have firewall rules that steer DNS queries to the proper places.
