Why does Gnome VPN include DNS servers that are not in specified list?

Unveiling DNS Behavior in Gnome VPN: Why Unexpected Servers Persist
We have observed a peculiar behavior in Gnome’s VPN implementation, specifically within the Gnome 48 environment, where manually configured DNS settings appear to be partially overridden, leading to unexpected DNS server entries in /etc/resolv.conf
. This situation, where the specified DNS servers are supplemented by a default DNS server (often belonging to the local network), necessitates a deep dive into the underlying mechanisms of Gnome’s network management system, NetworkManager, and its interaction with VPN configurations. Our objective is to dissect this behavior, providing a comprehensive understanding of its root causes and exploring potential solutions. We aim to assist users, like the one who raised the initial query, in fully comprehending and rectifying this situation.
Understanding the Expected Behavior of VPN-Configured DNS
The core principle of employing a VPN, especially in terms of DNS resolution, is to encapsulate and redirect all network traffic, including DNS queries, through the VPN tunnel. This ensures that DNS resolution is handled by the VPN provider’s designated DNS servers, thus shielding the user’s actual location and internet activity. When configuring a VPN connection within Gnome (or any other network management tool), one would reasonably expect that specifying particular DNS servers would result in only those specified servers handling DNS queries once the VPN is active. Any DNS queries should be exclusively routed through the specified DNS servers, overriding any default DNS server settings defined by the local network. This would be achieved to prevent DNS leaks and provide maximum privacy and security while using the VPN.
Dissecting the Root Cause: NetworkManager’s DNS Handling
The observed behavior, where manually configured DNS servers are supplemented by unexpected DNS servers, points towards how NetworkManager manages DNS configurations, which is usually the issue that lies at the heart of the problem.
How NetworkManager Configures DNS
NetworkManager acts as the central hub for network connections in Gnome. It automatically manages network interfaces, connection profiles, and associated settings, including DNS configuration. NetworkManager obtains DNS server addresses through several methods:
- DHCP (Dynamic Host Configuration Protocol): When connecting to a network (e.g., your home Wi-Fi), NetworkManager receives the DNS server addresses from the DHCP server provided by your router.
- Static Configuration: The user can manually specify DNS servers in the connection settings within NetworkManager’s GUI or via command-line tools like
nmcli
. - VPN Configuration: The VPN client (e.g.,
openvpn
,strongswan
) can inject its own DNS server information, typically obtained from the VPN server during connection negotiation.
NetworkManager prioritizes DNS settings according to its internal logic. The exact prioritization can depend on the specific version of NetworkManager, the type of connection (Wi-Fi, Ethernet, VPN), and the configuration settings. The core issue lies in the method through which NetworkManager handles the VPN DNS configuration; it will often incorporate the DNS settings from the VPN connection while also retaining some aspects of the underlying network’s DNS configuration, especially if those are hardcoded or obtained through DHCP, resulting in the unintended inclusion of DNS servers from outside the VPN’s scope.
Impact of resolv.conf
resolv.conf
is a critical configuration file, as it dictates the DNS servers the system will query for hostname resolution. On systems managed by NetworkManager, this file is often dynamically generated and managed, changing frequently as network connections come and go, and their DNS configuration changes. This is why manually editing resolv.conf
is generally discouraged, as NetworkManager will likely overwrite these changes.
NetworkManager’s DNS Handling and VPNs
When a VPN connection is activated, NetworkManager is expected to update the DNS configuration to prioritize the DNS servers provided by the VPN. However, there are cases in which this process does not function as designed, leading to the behavior you are experiencing. NetworkManager might retain DNS server entries from other active or previously active connections, which results in the inclusion of undesired DNS servers alongside the ones you’ve specifically set for the VPN. This often occurs when the underlying network’s DNS settings persist or are automatically reintroduced.
Detailed Analysis of the User’s Scenario
Let us now analyze the user’s particular scenario, as it provides crucial insights into the problem. The user configured a VPN in Gnome 48, specified 8.8.8.8 and 8.8.4.4 as DNS servers, and disabled automatic DNS. Yet, after the VPN was active, the /etc/resolv.conf
file contained 192.168.1.1, which is likely the DNS server provided by the user’s local network (router).
Troubleshooting the User’s Configuration
To diagnose this issue thoroughly, the following steps would be crucial:
- Verify VPN Client Configuration: Determine the underlying VPN client being used (e.g., OpenVPN, WireGuard). Examining the client’s configuration file (e.g., the OpenVPN configuration file) can show how it is being set up to handle DNS. Specifically, check if the VPN server is sending DNS server information as part of the connection setup.
- Examine NetworkManager’s Connection Profile:
- GUI Inspection: Review the VPN connection settings within Gnome’s network manager. Verify that the specified DNS servers (8.8.8.8 and 8.8.4.4) are correctly entered and that automatic DNS is indeed disabled. Double-check the VPN connection profile.
- Command-Line Examination: Use
nmcli connection show <connection_name>
to inspect the connection’s configuration from the command line. This gives a more comprehensive view of all settings, including DNS-related ones.
- Monitor Network Traffic: Employ a network monitoring tool like
tcpdump
orWireshark
to capture DNS queries being sent from the system when the VPN is active. This will clarify which DNS servers are actually being queried. This information will give an accurate insight into what DNS requests are being made and which DNS servers are responding. - Check DHCP Settings: If the local network is assigning DNS servers via DHCP, confirm whether these settings persist after the VPN is active. The DHCP settings are likely being re-applied, and are the likely cause of the problem.
- Verify NetworkManager’s State: Check NetworkManager’s logs for any error messages or warnings that could indicate issues related to DNS configuration during the VPN connection. Look for messages concerning the VPN, DNS, and IP address assignment.
Potential Solutions and Workarounds
Addressing this issue requires a mix of understanding the network configuration, NetworkManager’s behavior, and the underlying VPN client.
- Modify NetworkManager’s DNS Handling:
- Setting
dns-never
: In the NetworkManager connection profile for the local network connection, add thedns-never
option. This instructs NetworkManager not to set any DNS servers from that connection. - Manual DNS Configuration: Within the VPN connection profile, explicitly specify the DNS servers you desire (8.8.8.8 and 8.8.4.4).
- Using DNS Servers within VPN Configuration: Within the VPN client configuration, ensure that the client sends DNS server information, to inform the system which DNS servers to use.
- Setting
- Client-Side DNS Resolution (for advanced users): For more technical users, consider configuring a DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) resolver within the local machine after the VPN connection is established. This offers additional security and ensures that all DNS traffic is encrypted, independent of the DNS servers set in
resolv.conf
. Tools likesystemd-resolved
can be configured for this purpose. - Firewall Rule: The user can configure a firewall rule, to prevent queries to any other DNS server than the one of the VPN (8.8.8.8 and 8.8.4.4).
- Restart NetworkManager: After making DNS configuration changes, restart NetworkManager (
sudo systemctl restart NetworkManager
) or reboot the system to ensure the changes take effect.
Detailed Steps for Implementing Solutions
1. NetworkManager Configuration Adjustments
Using
nmcli
(Command-Line Interface):- Identify Connection Names: List your network connections:
nmcli connection show
. Identify the connection names for both your local network (e.g., “Wired connection 1”, “Wi-Fi connection”) and your VPN connection. - Configure Local Network:
- Disable DNS for Local Network:
nmcli connection modify "Wired connection 1" ipv4.dns-never yes nmcli connection down "Wired connection 1" nmcli connection up "Wired connection 1"
- Disable DNS for Local Network:
- Configure VPN Connection:
Set DNS Servers for VPN (if not already done):
nmcli connection modify "Your VPN Connection" ipv4.dns "8.8.8.8,8.8.4.4" nmcli connection down "Your VPN Connection" nmcli connection up "Your VPN Connection"
- Identify Connection Names: List your network connections:
2. VPN Client Configuration (Example: OpenVPN)
If using OpenVPN, the configuration file (
.ovpn
file) should contain these lines:dhcp-option DNS 8.8.8.8 dhcp-option DNS 8.8.4.4
3. Monitoring Network Traffic
Using
tcpdump
:sudo tcpdump -i <your_vpn_interface> -n udp port 53
Replace
<your_vpn_interface>
with the name of the VPN interface (e.g.,tun0
,ppp0
). This command captures DNS packets (UDP port 53) on that interface. Examine the output to verify that the queries are being sent to the intended DNS servers.
4. Firewall Rules (Example: iptables
)
This method prevents DNS queries from escaping the VPN tunnel.
Allow Traffic on VPN Interface:
sudo iptables -A OUTPUT -o <your_vpn_interface> -p udp --dport 53 -j ACCEPT sudo iptables -A OUTPUT -o <your_vpn_interface> -p tcp --dport 53 -j ACCEPT
Block All DNS Queries Outside the VPN:
sudo iptables -A OUTPUT ! -o <your_vpn_interface> -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable sudo iptables -A OUTPUT ! -o <your_vpn_interface> -p tcp --dport 53 -j REJECT --reject-with icmp-port-unreachable
Save Rules:
The exact method depends on your system; the usual way is to save and configure the rules to be loaded at system boot.
sudo apt install iptables-persistent # On Debian/Ubuntu sudo netfilter-persistent save #Save the iptables rules
Or use
firewalld
orufw
if present on your system.
Long-Term Considerations and Best Practices
1. Regular Updates
Keep your system and associated packages, including NetworkManager and VPN clients, regularly updated. Software updates frequently include bug fixes and security patches that may address DNS-related issues.
2. Security Best Practices
- Use Secure DNS: Employ DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) to encrypt DNS queries, which prevents potential eavesdropping or manipulation.
3. Testing and Verification
- Regularly Test DNS Resolution: After configuring your VPN and DNS settings, test DNS resolution using tools like
dig
,nslookup
, or online DNS leak tests (e.g., ipleak.net) to confirm that your DNS queries are being routed through the VPN and the intended DNS servers.
4. Documentation and Reference
- Keep Documentation: Document your VPN setup, including all configuration steps and settings. If problems recur, this documentation makes troubleshooting easier. Reference guides and manuals for NetworkManager, the VPN client in use, and related system tools are helpful.
Conclusion: Ensuring Full DNS Control in Gnome VPN
The situation described, where unexpected DNS servers persist in the /etc/resolv.conf
file despite manual VPN configuration in Gnome, results from the interaction between NetworkManager, the VPN client, and the underlying network settings. By carefully examining the VPN client configuration, NetworkManager connection profiles, network traffic, and DHCP settings, and by implementing targeted solutions like modifying NetworkManager’s settings, you can successfully ensure that only the desired DNS servers are used when the VPN is active. In summary, the key steps involve understanding NetworkManager’s prioritization logic, correctly configuring the VPN client, and actively validating the final DNS settings to ensure your privacy and security while using a VPN within the Gnome environment.