1.0.1-SNAPSHOT-01-24-2007 unable to resolve internet addresses only for it self
-
pfSense computer is unable to resolve internet addresses, but
computers using pfSense as a DNS server(the dnsforwarder) have no problem
at all, and pfSense is able to resolve local static addresses ???.
Even Squid can't resolve internet dns addresses.It takes some minutes(not really sure how many)after reboot before i see this behavior.
Have even tried to restart the dnsmasq with the help of Status/Services/Restart Service,
but that does not resolve the problem.The only fix is to reboot the pfSense computer :(.
I am using the 1.0.1-SNAPSHOT-01-24-2007 version, because of it's failover capability.
Have not used pfSense before, only ClarkConnect for about 3.5 years on the same hardware
except for the extra WAN card and a different harddrive(I've kept the ClarkConnect harddrive just
in case pfSense does not like my computer, thus making it easy to switch back).Some info from some pfSense web pages, windows command prompt and the pfsense console:
pfSense console:
10) Filter Logs
11) Restart webConfiguratorEnter an option: 8
ping www.google.se
ping: cannot resolve www.google.se: Host name lookup failure
ping www.google.se
ping: cannot resolve www.google.se: Host name lookup failure
ping www.google.se
ping: cannot resolve www.google.se: Host name lookup failure
ping ap
PING ap.internal.ethernet (192.168.11.253): 56 data bytes
64 bytes from 192.168.11.253: icmp_seq=0 ttl=255 time=1.171 ms
64 bytes from 192.168.11.253: icmp_seq=1 ttl=255 time=0.470 ms
64 bytes from 192.168.11.253: icmp_seq=2 ttl=255 time=0.477 msWindows XP command prompt:
C:\Documents and Settings\veni>ping www.google.se
Pinging www.l.google.com [209.85.135.103] with 32 bytes of data:
Reply from 209.85.135.103: bytes=32 time=26ms TTL=241
pfSense web gui package tab:
System: Package Manager
Unable to communicate to pfSense.com. Please check DNS, default gateway, etc
ISP1(WAN) DNS servers
195.67.199.39
195.67.199.40
195.67.199.41ISP2(OPT1) DNS servers
195.54.122.198
195.54.122.199
195.54.122.204
81.26.227.3"Allow DNS server list to be overridden by DHCP/PPP on WAN" is checked.
Status page:
Version 1.0.1-SNAPSHOT-01-24-2007
built on Thu Jan 25 16:09:53 EST 2007
Platform pfSense
Uptime 00:37
State table size 598/10000
Show states
CPU usage 1%
Memory usage 34%
SWAP usage 0%
Disk usage 2% -
You mention multiwan. I guess your DNS-Servers are not setup correctly and when WAN goes down your external DNS die. You have to use 1 DNS from each WAN at system>general and add a static route to the OPT-WAN DNS-Server through your OPT-WAN Gateway. Also if this is an upgraded install you possibly need to recreate your pools as the gui and config.xml for this has changed a bit. Just delete all poolmembers from the pools and readd them with the new gui. No need to delete the pools itself.
-
This happens while nothing is down, when everything runs as it should.
This is a fresh install.
This problem only applies to pfSense internal use of dns resolving, and happens first after several minutes of runtime.
When a client on the internal network uses pfSense as it's DNS server, everything works,
but not if the pfSense box want's to resolve a address itself e.g when using the Squid or Packages tab.I will give it a try with the static routes, because i will need them in case of a real WAN failure.
I will return with results.
-
I did as you suggested, but i had to un-check the checkbox named "Allow DNS server list to be overridden by DHCP/PPP on WAN", and then the ping command from the pfSense console worked right away, but not Squid(it could not resolve) and not the packages tab either. I also checked with traceroute to see that pfSense took the right WAN link depending on which dns server i ran a trace on.
I have now rebooted the box and now everything is working. Hope that was the last reboot for now.
Btw, inside windows i can use nslookup to find out what ipaddress a dns name has PLUS see which dnsserver that gave me that result.
Is there a function similar to nslookup inside pfSense? -
Damn, forgot to test the failover capability after the above change. Noticed it now when i was
playing around with the isp cables. After the above change the failover capability seems broken.
When pulling the plug for the primary ISP, both gateways are considererd offline according to the Status/Load Balancer,
and i loose all internet connectivity. Please notice that i don't pull the cable to the NIC on the pfSense computer, but a couple
of switches away from it.I have now turned back to previous settings, thus ignoring that squid and the pfSense computer cannot resolve addresses after a
couple of minutes of runtime, but at least the failover capability works. -
Sounds like you are depending on a common ip for monitoring. You really need a individual monitoring ip that is uplink and unique from each wan.
-
I really wish that it was like that, but i have used WAN failover within WatchGuard products before
and i use different ip's to ping. Each ip resides on each ISP's network.
It is set like this:WAN Monitor = 195.67.199.39
OPT1 Monitor = 81.26.227.3 -
I narrowed it down a bit. It had my secondary ISP's DNS server listed first in /etc/resolv.conf.
Moving them so that my primary are listed first solved my problem.I even tried something to narrow it a bit more, by entering a real ip address on the internet, but that does not run
a dns server, and every still worked. The resolver noticed that there was no dns server and resolved from the server
next in line.But…
as in my case, the resolver is trying to use ISP2 DNS server from my ISP1 connection, and both ISP's do not allow this,
and using host from pfSense shell console i get this:"www.google.se A record query refused"
It looks like if there is a valid dns server, but that responds in a way as above, the resolver
feels satisfied and does not move down the list.Questions:
1. Is there a way of forcing pfSense to use ISP1 DNS when primary link is working and
2. using ISP2 DNS when primary link is down.I have tried before using static entered DNS server addresses and using
static routes, and that fixed my DNS problem, but broke my failover capability .Static routes feel a bit non-safe(because of manually have to enter gateway ip, would work with just telling
pfSense: "Use WAN gateway IP"), because my primary ISP changes gateway depending on which WAN ip address i get,
and if my primary isp does some work on their equipment, then there is a 99% risk that i will get a different ip address
pointing to a different gateway.Btw, i found why it took some minutes after reboot before this problem presented it self:
If i edit /etc/resolv.conf to use the list in the correct order, after a couple of minutes that
list had changed back. All probably because i let dns servers from the dhcp data to be used,
thus the dhcp rewrote /etc/resolv.conf. -
It looks like i did something wrong sometime ago when trying to use static routes
and probably missed writing a static route for the IP address that i ping on OPT1 interface,
thus that making both WAN & OPT1 shown as Offline in Status/Load Balancer when doing a failover.Every client on the network works fine while browsing when on failover, but
the pfSense computer has some performance issues at this point with
DNS resolving from within the pfSense console using host, because it takes several seconds
to resolve for example www.google.se which only takes below half a second when everything is
running normal.When the primary WAN is offline(load balancer status) and my first static DNS server is the first on the list,
will pfSense still try to use the WAN NIC(i have added static routes for the DNS servers) to contact my first DNS server?
Or does it notice this itself and thus going directly for the second DNS server(it too has a static route pointing to OPT1)?
I'm trying to locate the source of the problem.I even noticed that my static routes were gone from Diagnostics/routes, but they were still in
System/Static Routes. Had to edit one entry(but not changing anything in it) to get the Apply button to appear.
After pushing the button, my static routes were back in the route table. Strange ???.