Provider-neutral self-test pilot
IVPN does not use the phrase kill switch: it ships a Firewall, and the difference matters when you read a failed check. The Firewall can be set to always-on so it protects the system all the time, including during boot, and IVPN documents it as making it impossible for IPv6 traffic to leave outside the tunnel while it is enabled. The readings cover this browser on this connection and nothing wider.
Live test
IVPN ships a Firewall rather than a kill switch and documents IPv6 as unable to leave outside the tunnel. Read the IPv6 and DNS lines against that.
Current-session checks
Take one reading unconnected and one connected. On IVPN almost every line traces back to a single setting - whether the Firewall is off, on demand, or always on - so establish that first.
Before you read the result
IVPN's knowledge base is the source for each point below, and on this provider almost everything traces back to one setting.
IVPN describes a firewall that only allows traffic through the VPN tunnel and blocks everything else, configurable either on demand or always-on so it covers the system all the time, including during boot. That last mode is the one that closes the window between the machine starting and the app connecting, which is where a surprising reading often comes from.
IVPN says its apps replace the system DNS with IVPN's own servers, and that the Firewall adds rules blocking all plain-text DNS queries sent to a non-IVPN DNS server. A DNS check while connected should therefore name IVPN, and a query that simply fails rather than resolving elsewhere is that rule working.
With the Firewall enabled, IVPN states it is impossible for IPv6 traffic to leak outside the VPN tunnel, and that the firewall protects against DNS, IPv6 and disconnection leaks together. So on IVPN an IPv6 result and a DNS result are not independent readings; they are two views of the same setting.
IVPN's apps for Windows, macOS and Linux let you list IP addresses and subnets that bypass the firewall, for cases such as reaching a device outside the current LAN range or running a corporate VPN at the same time. An exception you added earlier is the first explanation to rule out when something leaves outside the tunnel.
AntiTracker blocks ads, malicious sites and trackers at the DNS layer, which can explain a resource that refuses to load during a check. It does not touch WebRTC candidates or fingerprint values: those come from the browser, and IVPN publishes its apps as open source rather than claiming to fix them from inside the client.
Between the readings
IVPN ships a Firewall rather than a kill switch, and its three states - off, on demand, always on - differ mainly in when they start blocking. A recorded disconnect is where that difference becomes a number instead of a setting.
Safe Copy exports use safe summary categories and remove raw IP, exact city, full user-agent, raw fingerprint data, raw resolver IPs and WebRTC candidates. It is not a certificate, provider audit, or proof of anonymity.
FAQ
IVPN calls it the Firewall rather than a kill switch. It allows traffic only through the VPN tunnel and blocks everything else, and it can be set to on demand or always-on.
IVPN documents the always-on Firewall as protecting the system all the time, including during boot. That closes the gap between the machine starting up and the VPN app finishing its connection.
IVPN states that when its Firewall is enabled it is impossible for IPv6 traffic to leak outside the VPN tunnel. If an IPv6 check still returns your own address, the Firewall state is the first thing to confirm.
IVPN's Firewall adds rules that block plain-text DNS queries sent to any non-IVPN DNS server. A query that fails rather than being answered by another resolver is that rule doing its job.
Yes. IVPN supports firewall exceptions on Windows, macOS and Linux, letting named IP addresses and subnets bypass it for a device outside the LAN range or a corporate VPN. Check the exception list before treating the result as a fault.
AntiTracker blocks ads, malicious domains and trackers at the DNS layer, so it can stop a resource loading during a check. It does not change WebRTC or fingerprint values, which the browser produces locally.