[pfSense] DNS not resolving

I am trying to set up a pfsense router that is running FreeBSD 7.2 and pf filter for the firewall.

we have an IP of 97.89.176.86 /30
gateway 97.89.176.85
netmask 255.255.255.252

I can ping the gateway from the router but I do not get DNS resolution. I cannot ping other IPs from the router.

When we run:

netstat -r

Our network devices display very slowly or time out.

When we turn off DNS look ups and run

netstat -rn

The routing table is very promptly and correctly displayed.

The gateway has the flags:

Code:
97.89.176.85 UGW
97.89.176.86 UHLW

I think the DNS resolution is not being correctly performed. I remember this happening previously about 4 years ago it there was something miss configured on the private LAN but I can't find the previous solution to fix the problem.

Any suggestions?

Thanks in advance.

Sam Bowen
http://www.openmedsoftware.org
 
What the contents of your "/etc/resolv.conf" file? If netstat has to do reverse name lookups (IP addres -> name) it will use the name servers it finds in "/etc/resolv.conf"
 
Can you ping dns from client machine at all? Or better give us ouput of `traceroute -nI YOUR_DNS`
 
What the contents of your "/etc/resolv.conf" file? If netstat has to do reverse name lookups (IP addres -> name) it will use the name servers it finds in "/etc/resolv.conf"

cat /etc/resolv.conf

Code:
domain openmedsoftware.org
nameserver 24.158.63.8
nameserver 24.158.63.9

Can you ping dns from client machine at all?

No. I cannot.

Or better give us ouput of `traceroute -nI YOUR_DNS`

From the router:

# traceroute -nI YOUR_DNS

Code:
traceroute: unknown host YOUR_DNS


Traceroute to the WAN IP:

# traceroute -nI 97.89.176.86

Code:
traceroute to 97.89.176.86 (97.89.176.86), 64 hops max, 60 byte packets

 1  97.89.176.86  0.189 ms  0.132 ms  0.124 ms

Traceroute to the gateway:

# traceroute -nI 97.89.176.85

Code:
traceroute to 97.89.176.85 (97.89.176.85), 64 hops max, 60 byte packets

 1  97.89.176.85  0.568 ms  0.399 ms  0.379 ms

Traceroute using the IP address of the DNS server:

# traceroute -nI 24.158.63.9

Code:
traceroute to 24.158.63.9 (24.158.63.9), 64 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
^C

Routing tables IPv4:

Code:
default 97.89.176.85 UGS 0 4253 1500 re0 *beep* 
97.89.176.84/30 link#1 UC 0 0 1500 re0 *beep* 
97.89.176.85 00:22:2d:57:70:8d UHLW 2 2006 1500 re0 914 
127.0.0.1 127.0.0.1 UH 0 0 16384 lo0 *beep* 
192.168.198.0/24 link#2 UC 0 0 1500 em0 *beep* 
192.168.198.245 00:1f:16:e2:33:48 UHLW 1 77 1500 em0 1187

Routing tables IPv6:

Code:
::1 ::1 UHL 1 0 16384 lo0 *beep* 
fe80::%re0/64 link#1 UC 0 0 1500 re0 *beep* 
fe80::214:6cff:fec1:b578%re0 00:14:6c:c1:b5:78 UHL 1 0 1500 lo0 *beep* 
fe80::%em0/64 link#2 UC 0 0 1500 em0 *beep* 
fe80::211:11ff:fe1f:639d%em0 00:11:11:1f:63:9d UHL 1 0 1500 lo0 *beep* 
fe80::%lo0/64 fe80::1%lo0 U 0 0 16384 lo0 *beep* 
fe80::1%lo0 link#3 UHL 1 0 16384 lo0 *beep* 
ff01:1::/32 link#1 UC 0 0 1500 re0 *beep* 
ff01:2::/32 link#2 UC 0 0 1500 em0 *beep* 
ff01:3::/32 ::1 UC 0 0 16384 lo0 *beep* 
ff02::%re0/32 link#1 UC 0 0 1500 re0 *beep* 
ff02::%em0/32 link#2 UC 0 0 1500 em0 *beep* 
ff02::%lo0/32 ::1 UC 0 0 16384 lo0 *beep*

Sam Bowen
http://www.openmedsoftware.org/
 
drbowen said:
# traceroute -nI YOUR_DNS

Code:
traceroute: unknown host YOUR_DNS

Oh, come on ... traceroute the IP addresses of the nameservers in /etc/resolv.conf!
 
Code:
default 97.89.176.85 UGS 0 4253 1500 re0 *beep*
97.89.176.84/30 link#1 UC 0 0 1500 re0 *beep*
97.89.176.85 00:22:2d:57:70:8d UHLW 2 2006 1500 re0 914
127.0.0.1 127.0.0.1 UH 0 0 16384 lo0 *beep*
192.168.198.0/24 link#2 UC 0 0 1500 em0 *beep*
192.168.198.245 00:1f:162:33:48 UHLW 1 77 1500 em0 1187

Your routing table has the following addresses;
  • 97.89.176.85
    Code:
    $ dig +short -x 97.89.176.85 @24.158.63.8
    97-89-176-085.static.gnvl.sc.charter.com.
    This one resolves


  • 97.89.176.84
    Code:
    $ dig +short -x 97.89.176.84 @24.158.63.8
    97-89-176-084.static.gnvl.sc.charter.com.
    Ok too.


  • 97.89.176.85
    Code:
    $ dig +short -x 97.89.176.85  @24.158.63.8
    97-89-176-085.static.gnvl.sc.charter.com.
    Also resolves.

  • 127.0.0.1
    Code:
    $ dig +short -x 127.0.0.1 @24.158.63.8
    localhost.
    Fourth succes

  • 192.168.198.245
    Code:
    $ dig +short -x 192.168.198.245 @24.158.63.8
    This one fails. Of course that is a private RFC 1918 address. If you want that to resolve, you need a local nameserver.

Try on the pfsense box if you can resolve these addresses like I did from my box here in NL.
 
Dear DutchDemon:

Thanks for the tips on the other forums.

"Oh, come on ... traceroute the IP addresses of the nameservers in /etc/resolv.conf! "

Sorry about the "# traceroute -nI YOUR_DNS"

This is actually a legitimate command and works in Gentoo Linux. I apologize for assuing this would actually work in FreeBSD so I did literally what you said. I then went on to traceroute the LAN IP, WAN IP, the gateway all of which worked. When I do a ping or traceroute on the IP of the DNS servers 24.158.63.9 or 24.158.63.8, or any other IP outside of the gateway itself they ALL time out after very long periods. This was all included in the above posts.

If you go back and read my both of my posts, I have actually answered your question about pinging the DNS servers multiple times. So perhaps you would do me the courtesy of reading the entire post before cracking me over the head for making a error.

Sam Bowen, MD
http://www.openmedsoftware.org/
 
Assuming that you want your pfSense box NAT'ing for a RFC 1918 network, pfSense out of the box should be able to resolve DNS for hosts on the private network with just a couple of clicks.

Since you have already sat a static IP address, the next thing that you need to configure on the pfSense box is the upstream DNS servers:

System > General Setup

Then set your pfSense to forward LAN DNS requests:

Services > DNS Forwarder
 

Attachments

  • pfSense-DNS.PNG
    pfSense-DNS.PNG
    8.2 KB · Views: 6,142
  • pfSense-DNS_forwarding.PNG
    pfSense-DNS_forwarding.PNG
    16.9 KB · Views: 6,071
I am not familiar with pfsense but AFAIK he already configured his upstream nameservers. In post #4 he posted his "/etc/resolv.conf" file:
Code:
domain openmedsoftware.org
nameserver 24.158.63.8
nameserver 24.158.63.9
Looks like he already did configure them isn't? ;)
 
J65nko said:
Looks like he already did configure them isn't? ;)
Conclusively, all you can really say is that a host has been configured for DNS.

:e

Since the OP didn't say exactly, one can only assume that the resolv.conf file is from the pfSense box. However, you also need to keep in mind that pfSense is primarily configured via a web interface instead of the command line.

dig, nslookup and host are not available from the command line on the pfSense box:
Code:
# dig
dig: Command not found.
# nslookup
nslookup: Command not found.
# host
host: Command not found.
What may be important here is what the OP did not say. There are so many things that you can configure on the box, it is hard to say what customizations could be interfering.

I have pfSense running on an ip address that has a /23 subnet. It NAT's a 10.x class C and has been zero fuss.

My recommendation is to ignore what the box is doing and just boot from a live CD and configure it. It will ask you what your WAN and LAN ip address/subnets are, what the DNS and DHCP parameters are and *poof* it works. If the live cd config works, then you know something is jacked on the box.
 
Drbowen,

The "/etc/resolv.conf" you posted is in perfect health ;)

I wonder whether you are accidently blocking outgoing and/or incoming DNS traffic (port 53 UDP and TCP). Because each DNS request is repeated a few times before timing out, this can cause a substantial delay.

Even if you allow DNS requests originating from your local network to pass through the pfsense firewall, it is still possible that DNS requests issued from the pfsense box itself, like netstat -r does, are being blocked.
 
Resolved.

I liked johnblue's suggestion of trying the liveCD. Everything came up working. Now a new install is working just fine. I don't know what I did wrong in the initial installation but everything is now status green.

Thanks for your time and suggestions.

Sam Bowen
http://www.openmedsoftware.org/
 
Back
Top