OpenVPN back-toback DNS problem



  • 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



  • Server Side:
    Network: 192.168.0.0/22

    Looking for trouble there.



  • @kejianshi:

    Server Side:
    Network: 192.168.0.0/22

    Looking for trouble there.

    Why?



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



  • @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



  • 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.



  • @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




  • 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.


Log in to reply