Fixed Exit Case Study: A Stolen Agent Token Reaches Nothing Its Policy Refuses, Even Sent Straight to the Exit

An attacker steals an agent’s token and sends requests straight to the exit, skipping the agent’s machine. Exit checked each one against the agent’s own policy again, and nothing it refused got through. That was VPN Works 0.2.0. It’s back in 0.7.0, as vpnw exit, inside vpnw itself.

Partners and internal systems often let traffic in by IP address, so agents and CI jobs need fixed addresses to leave from. The usual answer is a proxy with a fixed address. A plain proxy trusts whatever reaches it with the right token, so a stolen token is a key to everything the address can reach.

Exit, in 0.2.0, was a server with fixed addresses that decided every request again with the client’s own policy before connecting.

Two Checks, Two Records

On the agent’s machine, vpnw checked the policy first. At the exit, the same policy was checked again, so skipping the agent’s machine gained the attacker nothing. Both ends recorded every connection, and the two records joined up on the run and connection IDs that vpnw sent with each request.

Where Exit Is Now

Exit is back in VPN Works 0.7.0, as vpnw exit, the server end of a path. The client side never left: vpnw reaches exits over TLS with their certificate checked, moves to the next exit in a list when one stops answering, and sends the run and connection IDs with every request. At the exit, the same code that decides a run’s connections decides every request again, with the client’s own policy.

This case is one of its tests now. A client with a valid token sent 11 forbidden requests straight to the exit, and all 11 were refused there; none reached a server. Exit · Exit in 0.7.0