You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was hoping that Passepartout supports what the native WG client does not: Split DNS. But it looks like it does not work as intended.
Steps to reproduce
Configure manual DNS by setting the DNS server IP to the internal DNS server (e.g. 172.16.1.1)
Configure the domain and search domain to point to the internal domain (e.g. internal.domain)
What is the current bug behavior?
172.16.1.1 will be used as default DNS server on iOS and macOS. This can be observed by checking the network traffic and will show that domains like apple.com are resolved through it as well.
What is the expected correct behavior?
172.16.1.1 should only receive DNS queries for internal.domain and it's subdomains, but not any other DNS queries.
Relevant logs and/or screenshots
Observations from scutil output on macOS
Global DNS settings will show the LAN search domain but the VPN DNS server
SupplementalMatchDomains being set to an empty string explains the behaviour (Apple documentation). Cloud it be that matchDomains is set to a value that includes and empty string?
The text was updated successfully, but these errors were encountered:
I've been building my own Wireguard app in macOS for a while now which includes this PR: WireGuard/wireguard-apple#11
It makes split DNS usable -- please consider incorporating it! You would have the privilege of offering the only (???) app store wireguard VPN with support for split DNS. (which wasn't bound to a specific VPN service, that is. I'm fairly sure the commercial offerings based on Wireguard make use of this macOS API already.)
Summary
I was hoping that Passepartout supports what the native WG client does not: Split DNS. But it looks like it does not work as intended.
Steps to reproduce
172.16.1.1
)internal.domain
)What is the current bug behavior?
172.16.1.1
will be used as default DNS server on iOS and macOS. This can be observed by checking the network traffic and will show that domains likeapple.com
are resolved through it as well.What is the expected correct behavior?
172.16.1.1
should only receive DNS queries forinternal.domain
and it's subdomains, but not any other DNS queries.Relevant logs and/or screenshots
Observations from
scutil
output on macOSSupplementalMatchDomains
Configuration screenshot
Possible fixes suggested remediation
SupplementalMatchDomains
being set to an empty string explains the behaviour (Apple documentation). Cloud it be thatmatchDomains
is set to a value that includes and empty string?The text was updated successfully, but these errors were encountered: