Is something changes on resolving domain name
-
I previously has snapshot of 6th Aug. But after updated to the current one (and tried a few in between), my VPN's cannot resolve the url
My VPNs are using url that have the same domain name as my internal domain and in turn this domain name is resolved "internally" by a dns server on one of the VPN links.
It works on the snapshot on or before 6th Aug. like that. i.e. pfSense will "directly" using the ISP or the assigned dns servers for any domain name resolving. I could using the Diagnostic:Ping to ping the url.
With the latest snapshot, I couldn't ping the url on Diagnostic:Ping. It seems the ping (and the VPN, filterdns) is trying to resolve the url from the dns server that actually on a VPN link (which cannot establish as the VPN url itself not resolving)
I also see there is one more entry on the DNS server on Dashboard which is 127.0.0.1 It seems pfSense is now resolving domain names using internal dns forwarder. Hence all my VPNs (except one is using no-ip.info) are broken.
Could the developer confirm whether this is intentional or just a bug?
Thanks.
-Raylund
-
That was an intentional change. If you are getting back private IPs from your upstream DNS servers, just uncheck the box for DNS rebind protection under System > Advanced.
-
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
-
My System log filled with the following:
filterdns: host_dns: failed looking up "gw51-xxx.ca": hostname nor servname provided, or not knownI 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
-
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 policyThis 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 knowni.e. even the resolved domain beforehand didn't resolve later; thus all my VPN links broken.
-Raylund
-
Can you show me the output of
dig @yourdnsserver $yourdomainname
dig $yourdomainnameJust to see what is going on here.
-
I put an option under System->Advanced-> Miscellaneous to allow restoring older behavior.
Test it with next snapshots. -
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
-
@ermal:
Can you show me the output of
dig @yourdnsserver $yourdomainname
dig $yourdomainnameJust to see what is going on here.
From 2.0-RC3 (i386) built on Sat Aug 6 19:02:34 EDT 2011
-
From 2.0-RC3 (i386) built on Fri Aug 12 00:28:10 EDT 2011
-
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 $yourdomainnamedig @192.168.20.17 hrl.ca
your first queries went to 156.154.70.22
-
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
-
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
-
Just fyi - the unbound package is updated. Which now correctly listens on the loopback address when it has been selected.
