Is something changes on resolving domain name

rlai000

My System log filled with the following:
filterdns: host_dns: failed looking up "gw51-xxx.ca": hostname nor servname provided, or not known

@rlai000:

I did as suggested but still have problem.

I think I should make it more clear by example.

I've an Active Directory setup in different offices/locations and connected via VPN (site-to-site IPSec). Not all offices have their own Domain Controller and DNS server. My office use DNS Forwarder to set "authoritative DNS server" for my AD domain to a remote office which has a DC and DNS server (via VPN).

Here is the problem. Let say my AD domain is called addomain.ca. This domain name, addomain.ca, is also a valid public domain on internet. I've setup DDNS (via easyDNS) that reference to other offices, e.g. gw0-surrey.addomain.ca, gw50-brampton.addomin.ca. My pfsense and other locations' SonicWall will using this url for VPN connection. And my DNS Forwarder for addomain.ca is referenced to, let say, the LAN (192.168.0.0/24) of gw0-surrey.addomain.ca.

As you could see now, my LAN will resolve addomina.ca to the DNS server on 192.168.0.0/24 via VPN. But now, pfsense try to resolve gw0-surrey.addomain.ca from the server in 192.168.0.0/24 which is not yet connected itself.

It's a catch 22 case now. Before the current snapshot, pfsense just resolve gw0-surrey.addomain.ca "externally" without problem. But now it try to resolve "internally".

I don't know whether this make my case a bit clear.

-Raylund

rlai000

More information.

It seemed the url of VPN resolved at the very first beginning for several links.

System log seeing several of my VPNs "reloading IPSec tunnel":
php: : Reloading IPsec tunnel '0.x_Surrey'. Previous IP 'xxx', current IP 'xxx'. Reloading policy

This is confirmed too in the "pfSense: status: cat /tmp/rules.debug" like:
pass out on $WAN route-to ( fxp1 xxx ) proto udp from any to xxx port = 500 keep state label "IPsec: 0.x_Surrey - outbound isakmp"
pass in on $WAN reply-to ( fxp1 xxx ) proto udp from xxx to any port = 500 keep state label "IPsec: 0.x_Surrey - inbound isakmp"
pass out on $WAN route-to ( fxp1 xxx ) proto udp from any to xxx port = 4500 keep state label "IPsec: 0.x_Surrey - outbound nat-t"
pass in on $WAN reply-to ( fxp1 xxx ) proto udp from xxx to any port = 4500 keep state label "IPsec: 0.x_Surrey - inbound nat-t"
pass out on $WAN route-to ( fxp1 xxx ) proto esp from any to xxx keep state label "IPsec: 0.x_Surrey - outbound esp proto"
pass in on $WAN reply-to ( fxp1 xxx ) proto esp from xxx to any keep state label "IPsec: 0.x_Surrey - inbound esp proto"

But some other VPN links are:

ERROR! Unable to determine remote IPsec peer address for gw22-xxx.ca

And after some time, say few minutes, all my System log filled with something like:
filterdns: host_dns: failed looking up "gw0-xxx.ca": hostname nor servname provided, or not known

i.e. even the resolved domain beforehand didn't resolve later; thus all my VPN links broken.

-Raylund

eri--

Can you show me the output of
dig @yourdnsserver $yourdomainname
dig $yourdomainname

Just to see what is going on here.

eri--

I put an option under System->Advanced-> Miscellaneous to allow restoring older behavior.
Test it with next snapshots.

johnpoz

Just noticed the 127.0.0.1 for dns as well, seems to be a bit of a problem if not using the internal forwarder. Using unbound and even though I highlighted both lan and loopback, unbound did not want to listen on 127.0.0.1

I had to manually edit the unbound.conf for it to listen on loopback, now for example looking to see if there is an update available on the dashboard again works.

Should prob bring this up in the package sections for unbound. If I highlight like below image and restart unbound shouldn't it listen on 127.0.0.1 as well as the lan interface

unboundloopback.jpg_thumb

rlai000

@ermal:

Can you show me the output of
dig @yourdnsserver $yourdomainname
dig $yourdomainname

Just to see what is going on here.

From 2.0-RC3 (i386) built on Sat Aug 6 19:02:34 EDT 2011

dig1.JPG_thumb

dig2.JPG_thumb

rlai000

From 2.0-RC3 (i386) built on Fri Aug 12 00:28:10 EDT 2011

dig3.JPG_thumb

dig4.JPG_thumb

johnpoz

you forgot the @ in your dig command – your just doing queries for the 2 different items.

Can you show me the output of
dig **@**yourdnsserver $yourdomainname
dig $yourdomainname

dig @192.168.20.17 hrl.ca

your first queries went to 156.154.70.22

rlai000

Thanks John.

Here are the outputs. One from old snapshot of 6th Aug and one is the most current one.

Both produced the same results.

-Raylund

dig1.JPG_thumb

dig3.JPG_thumb

rlai000

ermal,

I'm now running the latest snapshot 2.0-RC3 (i386) built on Fri Aug 12 09:36:08 EDT 2011

I got some funny results.

1st scenario, all my VPN connections are up and running.

But, Status:IPSec shows all "yellow crossed" box (except one is green box which url is referenced to no-ip.info).

The Status:System logs:IPsec VPN has all the proper connections transactions BUT they're not referencing to the usual "named"; they're all now IP addresses and numbers.

The Status:System logs:System still filled with "filterdns: host_dns: failed looking up "xxx": hostname nor servname provided, or not known".

2nd scenario is I did check the option in System:Advanced:Miscellaneous:DNS Forwarder:Localhost.

All is going back to normal as before.

Anyway, both scenario my VPN connections are working now. Except the 1st scenario that pfsense is very slow in respond when click on "Status:IPSec" and "Status:System logs:IPsec VPN".

Thanks

-Raylund

wagonza

Just fyi - the unbound package is updated. Which now correctly listens on the loopback address when it has been selected.