openvpn3-linux
openvpn3-linux copied to clipboard
OpenVPN
DNS queries does not work properly with v15_beta
After upgrading to v15_beta, I could no longer keep access to subdomains. All regular domains functioned as expected. e.g. my.domain.org works just fine, but my.other.domain.org does not.
I downgraded to v13_beta and no longer have this issue.
When using v15_beta, I could flush my cache and the subdomains would function once again, for about 30 seconds, then once again were inaccessible.
Can you provide the output of resolvectl when connecting to v15_beta and v13_beta.
Also, is /etc/resolv.conf a symlink to /run/systemd/resolve/stub-resolv.conf on your system? And what is the output of grep host /etc/nsswitch.conf?
The main difference between v13_beta and v15_beta is that openvpn3-linux integrates directly with systemd-resolved instead of manipulating /etc/resolv.conf. If /etc/resolv.conf is a symlink, systemd-resolved should pick up that change. But applications depending the glibc resolver might not query systemd-resolved if the nsswitch.conf file does not enable systemd-resolved.
I have a problem with DNS queries using v15_beta on Ubuntu 20.04. I can connect to the server without any issue, but the server IP address changes every day and the reconnection doesn't work to the new IP.
2021-08-08 22:28:14 Client DEBUG: Server poll timeout, trying next remote entry...
2021-08-08 22:28:14 Client INFO: Reconnecting
2021-08-08 22:28:14 >> Connection, Client reconnect
2021-08-08 22:28:14 Client DEBUG: Contacting 193.X.X.98:11941 via UDP
2021-08-08 22:28:14 Client VERB1: Waiting for server response
2021-08-08 22:28:14 Client DEBUG: Connecting to [szXXX.ddns.net]:11941 (193.X.X.98) via UDPv4
2021-08-08 22:28:24 Client DEBUG: Server poll timeout, trying next remote entry...
2021-08-08 22:28:24 Client INFO: Reconnecting
2021-08-08 22:28:24 >> Connection, Client reconnect
2021-08-08 22:28:24 Client DEBUG: Contacting 193.X.X.98:11941 via UDP
2021-08-08 22:28:24 Client VERB1: Waiting for server response
2021-08-08 22:28:24 Client DEBUG: Connecting to [szXXX.ddns.net]:11941 (193.X.X.98) via UDPv4
ping szXXX.ddns.net
PING szXXX.ddns.net (94.X.X.210) 56(84) bytes of data.
As you can see the "ping" gets a different IP address (94.X.X.210) than openvpn3 client (193.X.X.98) does. The openvpn3 doesn't update the IP of the domain name, that are trying to connect to the old IP address, but of cource it doesn't work.
/etc/resolv.conf is a symlink:
ll /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jul 31 2020 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
grep host /etc/nsswitch.conf
hosts: files dns
I have currently blocked @trash-80 for 30 days for closing an unresolved issue, in addition restored the initial OP message and issue subject as that is still relevant. This kind of behavior is unacceptable.
Hi,
I have the same issue : with the vpn on, not all dsn work properly. I've made the tests with v16_Beta instead of v15 since there's a newer version
v13_Beta resolvectl
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 6 (tun0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 5 (docker0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 4 (wlp58s0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (wwan0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (enp0s31f6)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.0.254
DNS Servers: 192.168.0.254
fd0f:ee:b0::1
DNS Domain: ~.
v16_Beta
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 6 (tun0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 10.100.224.97
DNS Servers: 10.100.224.97
DNS Domain: ~.
Link 5 (docker0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 4 (wlp58s0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (wwan0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (enp0s31f6)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.0.254
DNS Servers: 192.168.0.254
fd0f:ee:b0::1
DNS Domain: ~.
With v13, my /etc/resolv.conf is a file :
#
# Generated by OpenVPN 3 Linux (NetCfg::DNS::ResolvConfFile)
# Last updated: 2021-10-26 06:56:40
#
# OpenVPN defined name servers
nameserver 10.100.224.97
# System defined name servers
nameserver 127.0.0.53
# Other system settings
options edns0 trust-ad
With v16 I recreated the simlink : sudo ln -nsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
And lastly the hosts line in /etc/nsswitch.conf
➜ ~ grep host /etc/nsswitch.conf
hosts: files resolve dns mdns4_minimal [NOTFOUND=return] [!UNAVAIL=return]
I tested with and without resolve that I added after reading a stackoverflow thread on the subject, no changes.
I hope it will help.
First ... understanding the problem better
Can you please describe:
- What is not working for you in regards to the DNS queries? What you did you expect to see?
- Have you tried to flush the resolved cache? (
resolvectl flush-caches). - Which distro and systemd version are you running?
Switching back to the pre v14_beta behaviour of DNS configuration
For distributions known to ship with systemd-resolved enabled by default, this is how you revert back to the previous behavior. These instructions here requires v16_beta or newer. This is considered a "hackish quickfix" and not a sustainable solution.
Run all the commands presented here as root. First start by re-configure to modify directly /etc/resolv.conf and explicitly disable the systemd-resolved integration:
# openvpn3-admin netcfg-service --config-set resolve-conf /etc/resolv.conf
# openvpn3-admin netcfg-service --config-set systemd-resolved false
Then ensure you have no VPN sessions running (check with openvpn3-admin sessionmgr-service --list-sessions) and do a simple killall -INT openvpn3-service-netcfg. Double check that there are no openvpn3-service-netcfg processes running before you start the VPN connection again.
@Ferke85 I'm sorry to see you didn't get a reply on your challenge. This isn't necessarily related to this issue, but a different one we resolved in the OpenVPN 3 Core library, also included in v16_beta release. Please re-test v16_beta and open a new issue on your issue if you still experience this.