Is something changes on resolving domain name
-
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.
