VPN Privacy Audit Checklist: Test Your Kill Switch, DNS Leaks, and IP Address

Overview

A VPN creates an encrypted connection between your device and a VPN server. Websites and online services normally see the VPN server’s public IP address, while DNS requests should be handled according to the VPN’s configuration rather than being sent to an unintended resolver. The exact protection depends on the VPN application, operating system, browser, network, and settings.

A privacy audit does not prove that a VPN is safe in every situation. It is a practical way to identify common configuration failures and confirm that the service behaves as expected on a particular device. Run the checks once with the VPN disconnected, record the results, then repeat them with the VPN connected to a server. Save the date, device, operating system, VPN protocol, server location, and browser used.

For wider context on choosing a service, see our independent VPN comparison for the UK. If the VPN is being used for company systems, treat this audit as one control among others; it does not replace identity-based access controls, device management, or a broader remote access review.

Checklist by scenario

1. Establish a baseline before connecting

• Note the device, operating system, browser, network, and VPN application version.
• Visit a reputable IP address test page and record the public IPv4 address, approximate location, and internet provider shown.
• Run a DNS leak test and record the listed DNS resolvers and their apparent locations.
• Check whether the device has an IPv6 address. A VPN may protect IPv4 traffic while leaving IPv6 traffic outside the tunnel if IPv6 support or routing is incomplete.
• Record whether WebRTC reveals local or public network addresses in your browser.

These baseline results are not a pass or fail. They give you something to compare with the connected results and help distinguish a VPN issue from a normal property of the network.

2. Test the VPN connection

• Connect to a VPN server and confirm that the application reports an active connection.
• Repeat the IP leak test. The visible public address should normally change to an address associated with the VPN connection. If your original public address remains visible, investigate before using the connection for privacy-sensitive activity.
• Repeat the DNS test. Check whether requests are going to the VPN’s intended DNS resolvers or another resolver associated with your local network or internet provider.
• Repeat the IPv6 check. If the VPN does not support IPv6, determine whether the application blocks IPv6 traffic or provides a documented setting for handling it.
• Repeat the WebRTC test in every browser you use. WebRTC behaviour can vary between browsers, profiles, extensions, and operating systems.

Use a DNS leak test guide as a diagnostic aid rather than treating one website as definitive. Testing from a second independent service can help identify a misleading or incomplete result.

3. Test the kill switch

A kill switch is intended to prevent selected traffic from continuing over the ordinary connection if the VPN tunnel drops. It is not necessarily a universal device-wide block: some applications offer modes that protect only certain apps, destinations, or traffic types.

1. Read the VPN application’s description of its kill-switch modes before testing.
2. Connect to the VPN and open a simple page that displays your public IP.
3. Use the application’s disconnect, pause, or simulated connection-loss function if available. Avoid repeatedly disabling network adapters unless you understand the effect on the device.
4. Check whether protected traffic stops rather than falling back to the ordinary connection.
5. Reconnect and confirm that normal traffic resumes only after the VPN is active.

If you are troubleshooting Cisco AnyConnect or another managed client, use the relevant VPN troubleshooting guide as well. A consumer VPN kill switch and an enterprise access client may use different controls and policies.

4. Check the encryption and protocol settings

Open the VPN application’s connection details and record the protocol, encryption or cipher information, and any settings for DNS, IPv6, split tunnelling, automatic connection, and local network access. Do not assume that a marketing label alone describes the complete security of the connection. The surrounding configuration and the trustworthiness of the endpoint also matter.

For work devices, confirm whether split tunnelling is permitted. It can be useful for performance or access to local services, but traffic outside the tunnel will not receive the same VPN routing and policy treatment. For remote access decisions, compare the arrangement with the principles in our guide to ZTNA versus VPN.

What to double-check

Interpret the results in context

An IP address located near your chosen VPN server may be expected, but location databases are approximate and can be stale. A DNS resolver that appears in an unexpected country is not automatically a leak; first check the VPN provider’s documentation and the resolver details. The important question is whether DNS traffic is following your intended privacy and security policy.

Some VPNs support split tunnelling, local network access, or app-specific routing. These features can deliberately send selected traffic outside the tunnel. Write down the intended exceptions so that an audit can distinguish an approved route from an accidental leak.

Investigate a failed result methodically

1. Disconnect and reconnect to the VPN, then repeat the test.
2. Try another VPN server and, if appropriate, another supported protocol.
3. Temporarily disable browser extensions that alter DNS, proxy, or WebRTC behaviour, then retest.
4. Check the operating system’s proxy, DNS, and IPv6 settings.
5. Review the VPN application for kill-switch, leak-protection, and split-tunnelling options.
6. Test on a different network to determine whether the result is specific to the router or internet provider.

If the original IP address remains visible, DNS requests consistently bypass the VPN, or traffic continues after a documented kill-switch test, stop relying on the connection for the activity in question. Contact the provider or administrator with your recorded steps and results.

Common mistakes

• Testing only once: One successful result does not cover every browser, network, server, or protocol.
• Confusing a changed IP with complete privacy: A VPN does not prevent account tracking, browser fingerprinting, malware, or information voluntarily shared with websites.
• Ignoring IPv6: Checking only an IPv4 address can miss traffic that uses a separate network path.
• Assuming the kill switch is always active: Read its scope and confirm whether it covers all traffic or only selected applications.
• Testing while another proxy or VPN is enabled: Multiple network tools can make results difficult to interpret.
• Using sensitive data during a test: Use ordinary test pages and avoid entering credentials or confidential information into unfamiliar diagnostic sites.

A VPN is also not a substitute for HTTPS, strong account authentication, timely updates, or safe handling of files. For a broader set of controls, review this privacy tools checklist.

When to revisit

Repeat this VPN privacy audit before using a VPN for a new privacy-sensitive task, after installing or upgrading the VPN application, and after changing its protocol, DNS, IPv6, split-tunnelling, or kill-switch settings. Retest after a major operating system or browser update, when adding networking or privacy extensions, and whenever you change router, internet provider, or workplace network.

For teams, make the audit part of onboarding and seasonal planning cycles. Keep a short dated record of the device, configuration, test results, and any approved exceptions. Revisit it when workflows or tools change, when contractors receive access, or when a remote access design is being reviewed. Our guides to remote access security and short-term contractor access can help extend the review beyond the VPN client.

Printable quick check: record the baseline IP; connect to the VPN; verify the changed IP; test DNS; check IPv6; test WebRTC in each browser; confirm the kill switch blocks traffic during a controlled interruption; record protocol and routing exceptions; fix unexpected results; then retest after every relevant change.