Trouble with DNS search domains
Posted: Fri Sep 09, 2022 1:27 pm
Hi,
OpenVPN Connect 3.3.6 for OSX.
OS: tested on both Big Sur and Monterey.
Currently I'm building a new OpenVPN environment using Netgate PFsense+ 22.05. We're having several types of VPN clients: Linux, OSX and Windows. On OSX we run into trouble with the OpenVPN Connect client.
From the configuration we push DNS search domains to the client:
---
push "dhcp-option DOMAIN mgmt.domain.com";
push "dhcp-option DOMAIN office.domain.com";
push "dhcp-option DOMAIN domain.com";
push "dhcp-option DOMAIN-SEARCH mgmt.domain.com";
push "dhcp-option DOMAIN-SEARCH office.domain.com";
push "dhcp-option DOMAIN-SEARCH domain.com";
---
This works fine for the Linux clients, I can do a ping to a server without using the FQDN, just the hostname is fine since the client searches mgmt.domain.com for example. When I add an extra push:
---
push "dhcp-option ADAPTER_DOMAIN_SUFFIX mgmt.domain.com";
---
that also doesn't help.
In the log of the client it looks alright:
---
DNS Servers:
172.20.5.50
172.20.5.51
Search Domains:
mgmt.domain.com
office.domain.com
domain.com
Adapter Domain Suffix: mgmt.domain.com
---
and also in the client log:
---
MacDNSAction: FLAGS=F RD=0 SO=5000 DNS=172.20.5.50,172.20.5.51 DOM=mgmt.domain.com,office.domain.com,domain.com ADS=mgmt.domain.com
---
It looks like all the info gets to the client correctly, but it just doesn't add the search-domains. Also, when I use 'scutil --dns' the nameservers are there, also with the domains, but the domain mgmt.domain.com isn't added to the domains to search. resolving works just fine with FQDN, but not with just the hostname.
---
DNS configuration
resolver #1
search domain[0] : fritz.box
nameserver[0] : 192.168.1.1
if_index : 14 (en0)
flags : Request A records, Request AAAA records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records, Request AAAA records
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #4
domain : mgmt.domain.com
nameserver[0] : 172.20.5.50
nameserver[1] : 172.20.5.51
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 101400
resolver #5
domain : office.domain.com
nameserver[0] : 172.20.5.50
nameserver[1] : 172.20.5.51
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 101401
resolver #6
domain : domain.com
nameserver[0] : 172.20.5.50
nameserver[1] : 172.20.5.51
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 101402
---
I've also tried to use a script after the connection is 'up', but it seems OpenVPN Connect doesn't support that. In the log it show up as an unused option.
When I add a search domain to the network-settings of OSX it works, but the disadvantage is that when VPN is not up, the search-domains are leaked to the nameserver which is in use when VPN is not in use. Somehow I don't want to leak those to Google DNS...
Is this a bug? Or is there a workaround? Or are we being stupid and doing something wrong?
Kind regards, Jos Andel
OpenVPN Connect 3.3.6 for OSX.
OS: tested on both Big Sur and Monterey.
Currently I'm building a new OpenVPN environment using Netgate PFsense+ 22.05. We're having several types of VPN clients: Linux, OSX and Windows. On OSX we run into trouble with the OpenVPN Connect client.
From the configuration we push DNS search domains to the client:
---
push "dhcp-option DOMAIN mgmt.domain.com";
push "dhcp-option DOMAIN office.domain.com";
push "dhcp-option DOMAIN domain.com";
push "dhcp-option DOMAIN-SEARCH mgmt.domain.com";
push "dhcp-option DOMAIN-SEARCH office.domain.com";
push "dhcp-option DOMAIN-SEARCH domain.com";
---
This works fine for the Linux clients, I can do a ping to a server without using the FQDN, just the hostname is fine since the client searches mgmt.domain.com for example. When I add an extra push:
---
push "dhcp-option ADAPTER_DOMAIN_SUFFIX mgmt.domain.com";
---
that also doesn't help.
In the log of the client it looks alright:
---
DNS Servers:
172.20.5.50
172.20.5.51
Search Domains:
mgmt.domain.com
office.domain.com
domain.com
Adapter Domain Suffix: mgmt.domain.com
---
and also in the client log:
---
MacDNSAction: FLAGS=F RD=0 SO=5000 DNS=172.20.5.50,172.20.5.51 DOM=mgmt.domain.com,office.domain.com,domain.com ADS=mgmt.domain.com
---
It looks like all the info gets to the client correctly, but it just doesn't add the search-domains. Also, when I use 'scutil --dns' the nameservers are there, also with the domains, but the domain mgmt.domain.com isn't added to the domains to search. resolving works just fine with FQDN, but not with just the hostname.
---
DNS configuration
resolver #1
search domain[0] : fritz.box
nameserver[0] : 192.168.1.1
if_index : 14 (en0)
flags : Request A records, Request AAAA records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records, Request AAAA records
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #4
domain : mgmt.domain.com
nameserver[0] : 172.20.5.50
nameserver[1] : 172.20.5.51
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 101400
resolver #5
domain : office.domain.com
nameserver[0] : 172.20.5.50
nameserver[1] : 172.20.5.51
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 101401
resolver #6
domain : domain.com
nameserver[0] : 172.20.5.50
nameserver[1] : 172.20.5.51
flags : Supplemental, Request A records, Request AAAA records
reach : 0x00000002 (Reachable)
order : 101402
---
I've also tried to use a script after the connection is 'up', but it seems OpenVPN Connect doesn't support that. In the log it show up as an unused option.
When I add a search domain to the network-settings of OSX it works, but the disadvantage is that when VPN is not up, the search-domains are leaked to the nameserver which is in use when VPN is not in use. Somehow I don't want to leak those to Google DNS...
Is this a bug? Or is there a workaround? Or are we being stupid and doing something wrong?
Kind regards, Jos Andel