Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Cannot communicate with DNS Resolver over OpenVPN tunnel

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 4 Posters 4.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      godefroi
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • J
          jvcrabb
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • A
            Antimatter47
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              https://redmine.pfsense.org/issues/6730

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • A
                Antimatter47
                last edited by

                @jimp Thanks, that worked for me.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.