Cannot communicate with DNS Resolver over OpenVPN tunnel
Suddenly (it seems to me, possibly since the last pfSense update), I am unable to resolve DNS names across the OpenVPN tunnel. I was formerly able to do this, but it has stopped working. The firewall is definitely passing DNS traffic across to the LAN segment (see below), but for some reason the DNS Resolver on the pfSense box is inaccessible.
Both of my "Interfaces" settings in the resolver configuration are "All". My tunnel network is 10.56.235.0/24 and my resolver ACL has two networks in it, 192.168.10.0/24 and 10.56.235.0/24.
From the pfSense command line, I can successfully resolve:
> dig gateway @192.168.10.254 ; <<>> DiG 9.10.4-P2 <<>> gateway @192.168.10.254 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52322 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gateway. IN A ;; ANSWER SECTION: gateway. 1 IN A 192.168.10.254 ;; Query time: 0 msec ;; SERVER: 192.168.10.254#53(192.168.10.254) ;; WHEN: Wed Aug 03 14:19:33 MST 2016 ;; MSG SIZE rcvd: 52
Doing the same from over the VPN, however, times out:
> dig gateway @192.168.10.254 ; <<>> DiG 9.9.2-P2 <<>> gateway @192.168.10.254 ;; global options: +cmd ;; connection timed out; no servers could be reached
I can query a different DNS server over the VPN, however:
> dig gateway @192.168.10.241 ; <<>> DiG 9.9.2-P2 <<>> gateway @192.168.10.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58311 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gateway. IN A ;; ANSWER SECTION: gateway. 1 IN A 192.168.10.254 ;; Query time: 56 msec ;; SERVER: 192.168.10.241#53(192.168.10.241) ;; WHEN: Wed Aug 03 13:36:41 2016 ;; MSG SIZE rcvd: 52
I can see the states in the diagnostics/states page; the query that goes to .241 results in two states, one on the ovpns2 interface and one on the LAN. The query to .254 results only in the ovpns2 interface state.
What am I doing wrong, or what changed in the last pfSense update?
What was the previous version you were running where it worked?
Does anything show up in the resolver log when you try?
What if you raise the logging level in the DNS Resolver advanced options?
What is the source address that shows in the state table when you check? Just having one state for the VPN is OK if you're querying the firewall itself, but if the source IP address isn't in the ACL it would reject it.
Jimp and godefroi I am encountering the same issue except I have been using the DNS Forwarder instead of the Resolver.
I SSH'd into the firewall on the local network and ran tcpdump on the openvpn interface. I can see my test client sending DNS queries to the LAN interface on the firewall via the packet capture but I never see a response.
I have gone through and looked at the obvious things, like firewall rules but there is nothing in place that would be blocking it. I am the only one writing rules but I thought it was worth double checking in case I had a brain fart. I am able to route to the internet via IP addresses so I know I can route properly. Internal LAN IPs are reachable as well.
I am running 2.3.2-RELEASE (amd64).
I added one of the Open DNS servers to the DNS server list in the VPN configuration and after doing that things started working for me again.
I have a customer running 2.3.1-RELEASE-p5 (amd64) and we are not experiencing the same issue when I connect to their VPN. They are configured with the DNS Resolver (I never realized that DNS Forwarder is no longer the default, I guess I should update my setup LOL).
I am happy to provide more information, we are running a pretty vanilla remote access OpenVPN configuration on both firewalls, routing all traffic through the VPN.
I didn't find this thread until after I started my own here, but I am having the same problem since updating to 2.3.2.
@jimp Thanks, that worked for me.