Hi,
On 11/02/20 12:06, Reto Schneider wrote:
On 2/10/20 5:23 PM, Jan Just Keijser wrote:
the line
push "dhcp-option DNS 10.176.0.1"
is the main suspect here... my guess as to what happens is this:
1) VPN is started
2) that line causes the local /etc/resolv.conf file to be overwritten
with the new DNS setting
I just verified this: resolv.conf does not get adapted
I would also not have expected it because on the client side
"route-nopull" is specified.
if your clients would have an update-resolv-conf script then the file
would have been updated, regardless of 'route-nopull' - pushing a DNS
server is not overruled by 'route-nopull'
Also, I see in the clients log twice the following line:
Options error: option 'dhcp-option' cannot be used in this context
([PUSH-OPTIONS])
(Guess I should do [1]...)
My takeaway is that you think that this issue is because of funky DNS
stuff going on.
I will investigate some more in this area, but since I do not have
access to the affected devices (only logs), actions like taking down
OpenVPN to do analysis are pretty much impossible to do.
there's two things I would try in your case, but for both you need
access to a client device
1) replace 'remote example.com' with 'remote a.b.c.d' and see if that
particular client is not making connection attempts to seemingly random IPs
2) add a flag 'bypass-dns' to the "redirect-gateway" directive if that
is used on the client side to ensure that your DNS server is still
reachable after the VPN comes up
A short analysis of your problem is:
- it works the first time a client connects
- after a reconnect/wifi drop , the client resolves the remote host to
the wrong IP
conclusion: either the DNS server setting is modified OR the route to
the DNS server is altered by the VPN.
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
