After we upgraded one of our Access server installations to 2.12.0, some clients are no longer getting DNS settings when connecting to OpenVPN AS. We've only experienced the issue with clients running Fedora 38 and using NetworkManager. The same clients can connect without issues to another server still running 2.11.3. We see the following log entries on the client when connecting 2.11.3, but NOT on 2.12.0: [quote]Aug 30 10:33:30 mylaptop systemd-resolved[1075]: tun0: Bus client set search domain list to: example.net, another.com, internalstuff.local Aug 30 10:33:30 mylaptop systemd-resolved[1075]: tun0: Bus client set DNS server list to: 10.10.10.11, 10.10.10.12[/quote] I can't see anything relevant to DNS behaviour in the release notes for 2.12.0. Any thoughts on what might cause this?

Fedora clients no longer getting DNS settings after upgrade to 2.12.0

chort1

After we upgraded one of our Access server installations to 2.12.0, some clients are no longer getting DNS settings when connecting to OpenVPN AS. We've only experienced the issue with clients running Fedora 38 and using NetworkManager.

The same clients can connect without issues to another server still running 2.11.3.
We see the following log entries on the client when connecting 2.11.3, but NOT on 2.12.0:

Aug 30 10:33:30 mylaptop systemd-resolved[1075]: tun0: Bus client set search domain list to: example.net, another.com, internalstuff.local
Aug 30 10:33:30 mylaptop systemd-resolved[1075]: tun0: Bus client set DNS server list to: 10.10.10.11, 10.10.10.12

I can't see anything relevant to DNS behaviour in the release notes for 2.12.0. Any thoughts on what might cause this?

chort1

Some more information:
We tried downgrading NetworkManager on the client (from 1.42.8 to 1.40.18) and comparing log entries on the server, and it seems that the syntax for DNS settings being pushed differs quite a bit. This is taken from the 2.12.0 server

WIth 1.42.8 client (NOT WORKING)

'<snip>PUSH_REPLY,dns server 10 address 10.10.10.11,dns server 11 address 10.10.10.12,dhcp-option ADAPTER_DOMAIN_SUFFIX example.com,dns server 10 resolve-domains example.com another.net internalstuff.local,dns server 11 resolve-domains example.com another.net internalstuff.local,register-dns,block-ipv6,<snip>,push-continuation 2' (status=1)"

With 1.40.18 client (WORKING)

'<snip>PUSH_REPLY,dhcp-option DNS 10.10.10.11,dhcp-option DNS 10.10.10.12,dhcp-option DOMAIN example.com,dhcp-option DOMAIN another.net,dhcp-option DOMAIN internalstuff.local,ADAPTER_DOMAIN_SUFFIX example.com,register-dns,block-ipv6,<snip>,push-continuation 1' (status=1)"

chort1

Disregard the part about NetworkManager. It seems the syntax change was caused by downgrading openvpn (from 2.6.6 to 2.5.9)

chort1

So our current findings indicate that perhaps openvpn 2.6.x in combination with OpenVPN Access Server 2.12.0 agree to send DNS parameters in a format that NetworkManager/systemd-resolved doesn't accept.

Is there any hope for a confirmation on this from an official source?

openvpn_inc

Hello chort1,

OpenVPN 2.6 and OpenVPN Connect v3.4 both introduced the new 'dns' directive. Access Server will use this if these clients connect. The intention is that this will unify the behavior between openvpn2 and openvpn3 and on all the different operating systems. Behavior is different across all of these at the moment. The new dns directive aims to solve this over time and unify it as one single predictable dns system. We are actively working to implement it across as many platforms as possible but on Linux things are a little tricky.

On Linux, with openvpn2, the handling of dns is not built into the program. Instead it relies on an external program or script to deal with it. It looks like that program or script doesn't understand the new dns directive.

What you can do is implement the old dhcp-option method in Access Server for now, until whatever program or script you're using is able to understand the new dns directive. To do this go to the Admin UI, Configuration, Advanced VPN, and in the 'server config directives' field add this;

push "dhcp-option DOMAIN internalstuff.local"
push "dhcp-option ADAPTER_DOMAIN_SUFFIX example.com"

Then the old behavior is restored. In the future when your software gets the necessary changes to understand the new dns directive, it can be removed.

Kind regards,
Johan

chort1

Hi and thanks for the input. I also ran the problem through support, and they pointed me in the same direction.

Btw, my client didn't appear to respect the ADAPTER_DOMAIN_SUFFIX directive, but DOMAIN-SEARCH seemed to work.