Your VPN gateway is compromised: what is actually exposed
A hacked VPN gateway sees inside its own tunnel, but that is not owning every session. Separate traffic, reach and stored secrets before recovery.
A VPN gateway sits at the end of the tunnel it protects, which means it terminates that encryption rather than passing it through. If an attacker controls the host, the tunnel keeps looking healthy from outside while the machine in the middle is no longer trustworthy. The useful question is not whether everything is decrypted. It is what that host could see, what it could reach, and which secrets were actually stored on it. Those three answers differ a lot, and the response differs with them.
The gateway terminates the tunnel, so it sees inside it
Encryption in a VPN is hop by hop, and the gateway is the hop. It strips the outer layer, applies policy and forwards the inner packet, so every carried packet exists in readable form in that host's memory at some point. That is the design rather than a flaw. It is also why compromise of the gateway is a different event from compromise of the tunnel's cryptography.
What the attacker gains first is position: the ability to observe carried traffic, alter forwarding, or answer in place of a backend. What they gain next depends on the host, and this is where people overestimate. Gateway access alone does not hand over a browser's TLS session keys, because those were never on the gateway.
Three exposures that are not the same size
Split the question into carried traffic, reachable systems and stored secrets, then answer each one on its own.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
The middle row is the one that gets skipped. A gateway usually has a route into private networks and a source address the backends already trust, so the interesting question is what those backends permit from that address. A narrow client-access policy is a good control, but an attacker on the host is not limited to the interface a normal client would use.
The bottom row decides how long the incident lasts. A server key and a CA key have completely different blast radii, and so do a local admin account and a read-only monitoring token.
HTTPS inside the tunnel is still HTTPS
Application TLS terminates at the application, not at the VPN gateway, so a compromised gateway observes ciphertext for those flows. That is a real limit on what the attacker gets, and it is worth stating plainly, because the opposite claim spreads panic and bad decisions. Two conditions break it. If an inspection component holding a trusted certificate sits in the path, the gateway may see plaintext by design. If the application endpoint itself is compromised, the tunnel is irrelevant.
So the answer to what they saw is conditional, and it should be written down as conditions rather than announced as a verdict.
What has to change before you trust it again
Rebuilding the host is necessary and rarely sufficient. An attacker who still holds a management account, a deployment credential or a signing key can put the host back the way they like it. Recovery has to start from an administration path that does not depend on the compromised machine.
Inventory what was on it before deciding what to rotate. Keys, service accounts, API tokens, local users, scheduled jobs, trust relationships and the deployment pipeline are all candidates, and each has an owner who should confirm it.
ss -lntup
getent passwd
crontab -l
ip route show table allThat listing is the fastest way to see what the host was offering and where it could reach. Preserve the evidence first, under the response owner's process, because a rebuild destroys exactly what an investigation needs. NIST SP 800-61 Revision 3 treats preparation, detection, response and recovery as parts of one risk process rather than as a restart instruction.
Boundaries that make the next one cheaper
Four boundaries are worth building before you need them. Keep an independent recovery path that does not authenticate through the gateway. Keep signing authority separate from the host that serves traffic. Limit what the gateway can reach, so a compromised gateway is not automatically a compromised management network. And record who owns each credential, so rotation is a phone call instead of an archaeology project.
None of these prevent compromise. They bound it, and they make the difference between a bad week and a bad quarter.