The Default VPN Settings That Betray You

When a VPN application opens, the settings screen is a list of switches. Most are already toggled to the position that the developers chose before you ever installed the software. This is not a coincidence. It is a calculation based on the number of support tickets the company can afford to process. A default configuration is designed to work for the largest possible number of users on the widest possible range of networks. It is not designed to protect any specific user from a specific threat.

The tension here is fundamental. A setting that maximises security often breaks compatibility. If a VPN forces a strict protocol that a corporate firewall blocks, the user cannot connect. They cannot work. They call support. If a VPN allows traffic to split between the tunnel and the local network, it works everywhere, but it leaks. The developer chooses the latter because the cost of a support call is immediate and quantifiable. The cost of a leak is abstract and rarely reported. The default state is therefore a compromise that favours connectivity over privacy.

This means that when you press "Connect" and the icon turns green, you have not achieved a secure state. You have achieved a connected state. These are different things. The application is doing its job, which is to establish a link. It is not doing the job you assumed it was doing, which is to hide you. The gap between these two jobs is filled by settings that are off by default. You must find them and turn them on. The following four settings are the most common points of failure.

DNS Resolution and Local Leaks

The first setting to check is how the application handles Domain Name System requests. When you type a website address, your computer must ask a DNS server for the IP address. If this request goes through the VPN tunnel, your ISP sees only encrypted traffic. If it goes out through your local network interface, your ISP sees exactly which website you are visiting, even if the data itself is encrypted.

Many operating systems, particularly Windows, use a feature called multi-homed name resolution. This allows DNS queries to travel across all available network interfaces simultaneously. If the VPN does not explicitly capture and route these queries through the tunnel, the local DNS server handles them. The result is a DNS leak. Your traffic is hidden, but your destination is not. The setting to look for is often labelled "DNS leak protection" or "Send DNS over VPN". If it is off, your ISP can build a log of your browsing history.

The symptom of this failure is subtle. Your internet speed may be normal. Your connection may be stable. But if you visit a DNS leak test website, you will see your local ISP's IP address listed alongside the VPN server's IP. This is the definitive proof that the setting is off. The condition under which this stops being a problem is if you use a browser that handles its own DNS over HTTPS, but that is a workaround, not a fix for the VPN itself.

The Kill Switch and Connection Drops

The second critical setting is the kill switch. A kill switch is a safety mechanism that cuts your internet connection if the VPN tunnel drops. Without it, if the encrypted link fails, your traffic reverts to your unencrypted local connection. You continue browsing, but you are now completely exposed. The application may not even notify you that the tunnel has broken.

Developers often leave this off by default because it is disruptive. If the kill switch is on and the VPN drops, the user loses internet access. They may think the VPN is broken and uninstall it. They may call support to complain that their internet stopped working. By keeping it off, the application ensures that the user always has internet, even if it is not secure. The trade-off is that you may be browsing in the clear without knowing it.

The symptom of a missing kill switch is a period of unencrypted activity. You may not notice it at all. One moment you are protected, the next you are not, and the connection remains stable. The only way to know is to test it. Disconnect the VPN while browsing. If your internet remains active, the kill switch is off. If your internet stops, it is on. This is a hard requirement for any user who values privacy. Without it, the VPN is a suggestion, not a guarantee.

WebRTC and Browser Fingerprinting

The third setting concerns WebRTC, a technology built into web browsers that allows direct peer-to-peer communication. WebRTC can expose your local IP address even when the VPN is active. The browser uses it to find the best route for video calls and data channels. It does this by querying your local network interface, bypassing the VPN tunnel entirely.

Most VPN applications do not control browser behaviour directly. They cannot stop your browser from using WebRTC. However, some offer a setting to block WebRTC or to restrict it to local traffic only. If this setting is off, your browser may leak your real IP address to any website you visit. The website can then see that you are using a VPN, but it can also see your actual location.

The symptom is a discrepancy between your VPN IP and your browser's reported IP. If you check your IP on a website, it shows the VPN address. But if you run a WebRTC leak test, it shows your local address. This is a common oversight because users assume that the VPN covers the entire system. It does not. It covers the network stack, but the browser is a separate application that can bypass it. You must check the browser settings or the VPN's specific WebRTC toggle.

IPv6 and Protocol Mismatches

The fourth setting involves the Internet Protocol version 6, or IPv6. Many networks still use both IPv4 and IPv6. If your VPN only supports IPv4, any traffic that requires IPv6 will bypass the tunnel. This is because the VPN cannot encrypt traffic it does not understand. The result is a split-tunnel scenario where some of your traffic is protected and some is not.

The setting to look for is "IPv6 leak protection" or "Disable IPv6". If it is off, your device may send traffic over IPv6 directly to the internet. Your ISP can see this traffic. It is unencrypted and unmasked. The VPN icon is still green, but part of your traffic is leaking.

The symptom is the presence of an IPv6 address in your network interface when the VPN is connected. If you check your network settings and see an IPv6 address, and the VPN does not explicitly block it, you are leaking. The condition under which this is not a problem is if your ISP does not use IPv6, but that is becoming rare. Most modern networks are dual-stack. You must ensure that the VPN handles both protocols or that it disables IPv6 entirely. This is often a hidden setting, buried in advanced options.


← All warp pipe