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

    OpenVPN back-toback DNS problem

    OpenVPN
    2
    8
    837
    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.
    • marcelovvmM
      marcelovvm
      last edited by

      We have a scenario that the need to interconnect two offices and we are using PFSense in both sides (attached: my_conf.png) with the settings of this site https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_OpenVPN-connection_in_PfSense_2.1, that is all my client-side network traffic goes through the VPN and only accesses the internet from the server side. On the server side is our AD/DNS/DHCP Server (server side) which is a Windows 2008 R2. From the client side I configured another network (PFSense DHCP Server) and put the DNS being the AD of the (server side) and the GW being the PFSense of the client side.

      The "local" accesses are ok, however the internet browsing is intermittent DNS resolver, ie time we can navigate, time gives DNS error (unresolved). We switched DNS from client-side to Google-side (8.8.8.8) and navigation stabilized, but then "local" hits give you trouble when done using FQDN. We temporarily revamped the local accesses changing everything from FQDN to IP. Would you like to know what may be wrong with our settings?

      Server Side:
      Network: 192.168.0.0/22
      AD: 192.168.1.51
      GW: 192.168.1.22 (pfsense)
      DNS: 192.168.1.51 and 192.168.1.22
      VPN tunnel: 10.0.0.1

      Customer side:
      Network: 192.168.5.0/24
      AD: does not have (theoretically would be the same server side)
      GW: 192.168.5.1 (pfsense)
      DNS: 192.168.1.51
      VPN tunnel: 10.0.0.2

      Live long and prosper,
      Marcelo Magalhães
      my_conf.png
      my_conf.png_thumb

      1 Reply Last reply Reply Quote 0
      • K
        kejianshi
        last edited by

        Server Side:
        Network: 192.168.0.0/22

        Looking for trouble there.

        1 Reply Last reply Reply Quote 0
        • marcelovvmM
          marcelovvm
          last edited by

          @kejianshi:

          Server Side:
          Network: 192.168.0.0/22

          Looking for trouble there.

          Why?

          1 Reply Last reply Reply Quote 0
          • K
            kejianshi
            last edited by

            Its late - Sorry.  I thought it was 192.168.1.0/24

            1 Reply Last reply Reply Quote 0
            • marcelovvmM
              marcelovvm
              last edited by

              @kejianshi:

              Its late - Sorry.  I thought it was 192.168.1.0/24

              Ok, no problem. But what did you think when you answered? What would be the problem if the network is 192.168.1.0/24? My server side network is 192.168.0.0/22 and cliente side is 192.168.5.0/24, and these two subnet of C class do not "colide".

              Live long and prosper,
              Marcelo Magalhães

              1 Reply Last reply Reply Quote 0
              • K
                kejianshi
                last edited by

                Personally, I don't like your address ranges.
                I stay away fro ranges that will commonly appear elsewhere, like 192.168.1.0/24

                And ranges that overlap lots of other common ranges like your 192.168.0.0/22

                and 10.0.0.0 which is common as dirt.  For me, these ranges appear very often and its easy to end up with conflicts.

                However, assuming no conflicts exist, I'm not sure what is broken.  Still thinking about it.

                1 Reply Last reply Reply Quote 0
                • marcelovvmM
                  marcelovvm
                  last edited by

                  @kejianshi:

                  Personally, I don't like your address ranges.
                  I stay away fro ranges that will commonly appear elsewhere, like 192.168.1.0/24

                  And ranges that overlap lots of other common ranges like your 192.168.0.0/22

                  and 10.0.0.0 which is common as dirt.  For me, these ranges appear very often and its easy to end up with conflicts.

                  However, assuming no conflicts exist, I'm not sure what is broken.  Still thinking about it.

                  I've been thinking of the next.

                  The dns resolver of the computers on the client side (192.168.5.0/24) is my AD/DNS server (192.168.1.51). So… when a client browsing it triggers a DNS lookup (53) hitting the DNS server. Does the DNS server resolve the search and respond to whom? The 192.168.5.0/24 network is not directly connected to the DNS server. If so, the DNS lookup response will never reach the client. Could it be that? If it is ... how to solve it? Put a static route on the DNS server for the 192.168.5.0/24 network?

                  The routing table (attached), of DNS server, does not have a specific route to 192.168.5.0/24 network, so the DNS server will throw the DNS response to the default gateway, PFSense (192.168.1.22), which in theory should route this DNS query for the client you requested. Is my logic right? Should I configure something in PFSense (server or client) to work this way?

                  Live long and prosper,
                  Marcelo Magalhães

                  route_print.png
                  route_print.png_thumb

                  1 Reply Last reply Reply Quote 0
                  • K
                    kejianshi
                    last edited by

                    I'd probably put a route to the server in the openvpn client side and a route to the client subnet on the server side…  However, I'm not super genius, so may not work.

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