search

ivpn / desktop-app

Official IVPN Desktop app
https://www.ivpn.net/apps/
GNU General Public License v3.0
362 stars 50 forks source link

(macOS) Search domain not set when Custom DNS is enabled #49

Open jordan-ivpn opened 3 years ago

jordan-ivpn commented 3 years ago

Bug report

Describe your environment

Describe the problem

On macOS, [there is] an issue when I have Custom DNS configured to use my local DNS server IP. Even when that is configured, it still uses the IVPN resolver, which means it isn't using the DNS search domains configured with my local DNS.

As a result, I'm unable to connect to a network share using a hostname such as smb://NAS.local.lan

Steps to reproduce:

  1. Set a custom DNS server
  2. Connect the VPN
  3. Run scutil --dns to check the search domain

Observed Results:

$ scutil --dns

# Connected with AntiTracker enabled:

resolver #1
  search domain[0] : ivpn-client
  nameserver[0] : 10.0.254.2

# Connected with Custom DNS set to 1.1.1.1:

resolver #1
  search domain[0] : ivpn-client
  nameserver[0] : 1.1.1.1

# Disconnected:

resolver #1
  search domain[0] : domain.local
  nameserver[0] : 192.168.0.1

# Connected, Custom DNS set to local router, search domain set to local domain name

$ networksetup -setsearchdomains Ethernet local.lan
$ scutil --dns

resolver #1
  search domain[0] : domain.local
  nameserver[0] : 192.168.0.1

# Reset search domain 

$ networksetup -setsearchdomains Ethernet empty

Expected Results:

Use the resolver and search domains specified by the IP address when using the Custom DNS option. This works as expected on a different VPN provider (Private Internet Access)

Relevant Code:

n/a

stenya commented 1 year ago

Linked ticket: [Arch Linux] Improved handling of DNS search domains

stenya commented 1 year ago

(macOS) Now, the system-defined DNS search domains are preserved when the VPN is connected

stenya commented 1 year ago

@jordan-ivpn Can you confirm that the solution below is accurate? (see below)

Preconditions: The OS has a preconfigured DNS search domain(-s) (e.g., "home.lan").

Previous behavior: When the VPN was connected, and the user tried to load "NAS.home.lan" using the hostname "NAS", it failed because no search domains were defined during the VPN connection.

New implementation: When the VPN is connected, the original DNS search domains defined in the system are also used for the VPN connection. When the user tries to load "NAS.home.lan" using the hostname "NAS", the "NAS.home.lan" DNS requests are sent to the configured DNS server.

jordan-ivpn commented 1 year ago

@stenya

Can you confirm that the solution below is accurate? (see below)

I think so. As mentioned in the Arch ticket (https://github.com/ivpn/desktop-app/issues/267), it might be best to only allow access to the local DNS search domain when the Allow LAN traffic/Allow Multicast options are enabled. If these LAN options are not enabled, the app's firewall will block the "*.home.lan" requests, though there may or may not be a time-out involved as the local resolver tries to find the local DNS search domain.

Also, there must be a consideration for allowing the local resolution of "*.home.lan" hostnames only and not for any Internet hosts via the local LAN DNS server, otherwise, this is likely a DNS leak.

stenya commented 1 year ago

The IVPN firewall blocks IP addresses, not "search domains". The IVPN app can either preserve search domains or not use this configuration parameter for a VPN connection.

However:

So, accessing internal resources using DNS search domains depends on two parameters: "Allow LAN traffic" and "Custom DNS".

Additionally, "search domains" may be related not only to local networking (for example, having "google.com" in search domains will allow making DNS requests to "mail.google.com" by simply entering "mail"). Thus, I think it is not correct to allow "search domains" only when "Allow LAN traffic" is enabled.

Also, there must be a consideration for allowing the local resolution of "*.home.lan" hostnames only and not for any Internet hosts via the local LAN DNS server, otherwise, this is likely a DNS leak.

What kind of leak do you mean? Do you mean that local DNS requests may be forwarded outside of the internal network?

stenya commented 1 year ago

This functionality change will affect all users. Since we do not have a final understanding of how it should work and not many users require it, I am going to postpone this ticket (although I have already done some implementation). Let's keep track of customer requests and revisit this later.

jordan-ivpn commented 1 year ago

What kind of leak do you mean? Do you mean that local DNS requests may be forwarded outside of the internal network?

Resolve github.com via the VPN server DNS and resolve NAS.home.lan via the local DNS. If github.com is resolved by the local DNS, this might be a leak or it might not if making use of the local search domain and the local DNS is important or required.