OpenVPN Clients aren't always able to resolve DNS



  • I have an OpenVPN server setup on 2.4.4, and some users (Windows 10) when they connect to the OpenVPN client aren't able to resolve DNS queries. I have the configuration set to access the network the DNS server is on, provide that DNS server to clients, as well as force a DNS cache update on initiation.

    However, about 50% of the users when connecting can't connect to our DFS namespace which uses domain.com which also has a public IP if using a public DNS server. I'm pretty sure this is why they can't connect since they're trying to reach our public site, but the DNS settings should be updating for them forcing the traffic to that domain to go internal.

    I've restarted the OpenVPN service and that seemed to fix it temporarily, but obviously this isn't ideal.

    Any ideas? I can post more information as needed.



  • I've seen cases where there is intermittent access to a DFS namespace due to the DFS role not being installed on all domain controllers for that domain, but that would affect everyone and not just your VPN users.

    What is the actual error you are seeing? Or, what makes you believe it's a DNS issue? DNS is usually pretty stable and doesn't just pop in and out.



  • @KOM said in OpenVPN Clients aren't always able to resolve DNS:

    I've seen cases where there is intermittent access to a DFS namespace due to the DFS role not being installed on all domain controllers for that domain, but that would affect everyone and not just your VPN users.

    What is the actual error you are seeing? Or, what makes you believe it's a DNS issue? DNS is usually pretty stable and doesn't just pop in and out.

    After further investigation, I don't think DNS is the root cause, but a symptom.

    The clients are showing the route for our local network in their route print table, but any ping to an address in the local network times out. The OpenVPN network is 192.168.100.0/24, and the local network is 192.168.52.0/22.
    3aff31f7-7b4d-4400-b2f2-5a2eae3396bd-image.png
    I noticed that the destination for our OpenVPN network in the Routes diagnostic has the netif as the loopback. Is this a concern?

    12c94e3d-05a0-439e-9bd9-aae28e65e55d-image.png

    I'm comparing this with a branch office that has a very similar setup, and their netif is set to ovpns1.



  • That looks weird to me. I have:

    192.168.2.0/24	         192.168.2.2	UGS	46	1500	ovpns1	
    192.168.2.1	         link#8	        UHS	0	16384	lo0	
    192.168.2.2	         link#8	        UH	0	1500	ovpns1
    


  • @KOM said in OpenVPN Clients aren't always able to resolve DNS:

    That looks weird to me. I have:

    192.168.2.0/24	         192.168.2.2	UGS	46	1500	ovpns1	
    192.168.2.1	         link#8	        UHS	0	16384	lo0	
    192.168.2.2	         link#8	        UH	0	1500	ovpns1
    

    Yep, looks the same as the branch office.

    I do have an OPT1 interface assignment, is this an issue? Is it possible traffic coming into the VPN from clients is being sent to the internet because of this? If so, should I just remove the assignment?



  • I don't think it matters but I have my OpenVPN instance tied to my WAN address. I have 14 VIP-IP aliases and could have used anyone of them for the VPN but I stuck with the default.



  • @KOM said in OpenVPN Clients aren't always able to resolve DNS:

    I don't think it matters but I have my OpenVPN instance tied to my WAN address. I have 14 VIP-IP aliases and could have used anyone of them for the VPN but I stuck with the default.

    Mine's also tied to the WAN interface. I went ahead and removed the OPT1 assignment and I'm going to give it some time and have a few users test to see if it works now.


Log in to reply