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

    DNS Resolver forward over IPSEC site-to-site VPN

    Scheduled Pinned Locked Moved IPsec
    5 Posts 2 Posters 1.9k 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.
    • B
      byte0
      last edited by

      I have a site-to-site VPN link setup between two pfSense boxes. DNS for each site is handled by pfSense resolver service. I created a domain override in site B for siteA.local to forward to the LAN interface IP of the pfSense box at Site A.

      The pfSense box at Site B is not forwarding DNS requests to pfSense box at Site A. I ran tcpdump on ecp0 (udp 53 and tcp 853) at Site B and don't see DNS requests going out that interface.

      Is there a rule I need to create at Site B so that it will forward the DNS requests? I created Allow any rules on all interfaces at Site B, but no go. No DNS is forwarded to Site B.
      Any ideas?

      DaddyGoD 1 Reply Last reply Reply Quote 0
      • DaddyGoD
        DaddyGo @byte0
        last edited by

        @byte0 said in DNS Resolver forward over IPSEC site-to-site VPN:

        Any ideas?

        Hi,)
        It will be,....... in this place, the dog buried ๐Ÿ˜‰

        https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html

        f2fe5a72-5f4a-4d1f-b4f7-ec173a152793-image.png

        Cats bury it so they can't see it!
        (You know what I mean if you have a cat)

        B 1 Reply Last reply Reply Quote 1
        • B
          byte0 @DaddyGo
          last edited by byte0

          @daddygo Thank you for that. I can tell that DNS queries are making it there now. I just need to figure out why the DNS server at site A is refusing queries from Site B.

          Site A LAN IP = 192.168.3.253
          Site B LAN IP = 192.168.4.253

          In the shell of Site B

          dig @192.168.3.253 example.local
          
          ; <<>> DiG 9.16.12 <<>> @192.168.3.253 example.local
          ; (1 server found)
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41659
          ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
          ;; WARNING: recursion requested but not available
          
          ;; Query time: 1 msec
          ;; SERVER: 192.168.3.253#53(192.168.3.253)
          ;; WHEN: Tue Jun 22 21:54:43 PDT 2021
          ;; MSG SIZE  rcvd: 12
          
          1 Reply Last reply Reply Quote 0
          • B
            byte0
            last edited by

            I figured out the last part: In the pfSense GUI for the DNS Resolver there are no entries in the Access List, however after I searched for and found the configuration files, I noticed that pfSense automatically creates allow entries only for IP ranges of the interfaces on pfSense. I assumed then ( I didn't look it up in online man pages for unbound) that by default unbound refuses DNS requests unless an allow access-control entry exists.
            I went back to the GUI and created an Access List entry to allow the IP of the pfSense in Site B.

            All is well.

            DaddyGoD 1 Reply Last reply Reply Quote 0
            • DaddyGoD
              DaddyGo @byte0
              last edited by

              @byte0 said in DNS Resolver forward over IPSEC site-to-site VPN:

              All is well.

              Yup, it's best to be the master of your system, pfSense does not invent new things, it just implements what we already knew.... ๐Ÿ˜‰

              Thanks for your follow up

              Cats bury it so they can't see it!
              (You know what I mean if you have a cat)

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