TunnelCrack vs TunnelVision: What Each One Actually Breaks

Two research names get used interchangeably for any VPN traffic that leaves the tunnel, and the mechanisms behind them are not the same. TunnelCrack describes two families of routing exception; TunnelVision describes a DHCP-supplied route on the endpoint. Neither one breaks the encryption, and neither one tells you what a specific client build does today. Five checks separate the mechanisms from the headline.

Step one: name the mechanism you are reviewing

The TunnelCrack disclosure from August 2023 describes two attack families. In the local network case, traffic the client treats as belonging to the local network takes a local-access exception and leaves the tunnel. In the server address case, the route the client needs to reach the VPN server itself is outside the tunnel, and an adversary who controls that address can exploit the exception.

TunnelVision is a separate report about classless static routes delivered by DHCP. A rogue DHCP server can hand the endpoint routes that change which path traffic takes, including the path toward the VPN server. The report acknowledges earlier work on related routing effects, which is a reminder that the underlying mechanism is older than the name.

Keep the names attached to their mechanisms. Applying a fix for one because the other is in the news is how a review produces motion without coverage.

Step two: look at the local-access exception

Most clients exempt local network traffic so that printers, casting and file sharing keep working while the tunnel is up. That exception is a policy decision with a security cost: an adversary on the same network can present itself as a local host, and the traffic that reaches it never entered the tunnel.

Ask whether the deployed profile needs the exception at all. A remote workforce that never uses local discovery can often turn it off, and the remaining local services can be reached through a documented path instead. Where the exception is required, say which destinations it covers rather than describing it as local traffic.

The check is a configuration question, not a packet capture. Read the profile setting and the client documentation for the build you deploy, because the default differs between products and between versions of the same product. Write the answer next to the profile, so the next reviewer does not have to infer it from behaviour. An exception nobody documented is an exception nobody reviews.

Step three: look at how the server address is learned

The client has to reach the VPN server before any tunnel exists, so that destination is routed outside the tunnel by design. If the address is learned from a name, the resolution step is part of the trust path, and an adversary who can answer that query can point the client at a host they control.

Pinning the address, using a verified certificate with the correct name, and refusing to fall back to an unverified server all reduce the exposure. None of them removes the need to reach the server outside the tunnel; they change who can answer for that address.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

The route lookup shows the interface the client would use for the server address, which is the exception in concrete form. If that lookup returns the tunnel interface, the client cannot establish the tunnel in the first place, so an outside route is expected and the question is only how its destination is chosen.

Step four: look at DHCP-supplied routes

Classless static routes let a DHCP server hand out routing table entries, and the endpoint generally accepts them without asking. On a network where an adversary can answer DHCP faster than the legitimate server, those entries can redirect traffic that the user believes is inside the tunnel.

Compare the routes on the endpoint with the routes you expect. A default route or a broad prefix pointing at the local gateway while the tunnel is up is the signature worth investigating, and it is visible without any attack traffic.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

The last setting is the endpoint-side control that many clients and platforms expose in some form: ignore routes supplied by the network. Disabling automatic route acceptance is a trade-off, because it also disables legitimate split-routing from a corporate DHCP server, so decide it per network class rather than globally.

Step five: separate the advisory from the current build

A published attack describes behaviour observed on particular client versions at a particular time. It does not establish that the laptop in front of you is affected, and it does not establish that it is fixed. Both claims need the actual build number and the vendor's current advisory.

Record the client version, the platform, the profile settings that govern the exceptions above, and the date you checked. That record ages honestly, while a note that says the VPN was patched for TunnelCrack does not. Re-read it whenever the client updates, because a profile default can change under a version you did not touch.

When you do validate, use an approved plan against your own endpoint and a harmless destination. Reproducing the attack against other users on a shared network is not a test, and disabling peer verification or application encryption to make an observation easier removes the protection you were trying to measure.

Finally, keep application-level protection in the picture. A routing exception can expose traffic that the tunnel would have carried, and application TLS still protects that traffic end to end. The two layers fail independently, which is why a connected control channel is not evidence that every flow took the intended path.