Rogue VPN Router: Admission Control Before Decryption

An unknown router that appears on an internal switch port and immediately opens an outbound VPN has already passed the control that matters most. Admission decides whether the device gets usable network access at all, while decryption only tells you what it did afterwards. Getting that order right turns an impossible inspection problem into a routine port-policy question. It is also the difference between a reversible action and an outage.

Admission is decided at the port

Ask how the device obtained usable connectivity before you ask what its tunnel carries. A router attached to a live wall port, or a wireless client that joined an open SSID, was admitted by whatever policy that port or SSID applies. If that policy is "anything that plugs in gets a working VLAN", the VPN is a symptom rather than the vulnerability.

A DHCP lease is not an authorization record. Receiving an address, or failing to receive one, describes the address-assignment service, not the port's state, and plenty of designs let an unauthenticated device reach a helper while denying everything else. Treat the lease table as evidence about addressing, not about trust.

Three kinds of evidence get conflated in these investigations: an approved person, an approved managed device, and an entry on an inventory sheet. The port policy should be explicit about which of those it accepts, because a stolen credential and a cloned MAC address satisfy different ones.

What an authenticated port actually decides

With IEEE 802.1X, the switch or access point is the authenticator, and it forwards the supplicant's credentials to a central service as a RADIUS client. The RADIUS 802.1X attributes let that result authorize the port and, depending on the design, place the session in a particular VLAN or accounting context. The switch enforces whatever the policy server returns only if the port is configured to enforce it.

That last clause is where deployments quietly fail. A port left in monitor or logging mode records the would-be decision and still passes traffic, which looks like a working deployment in every report until someone plugs in an unmanaged router.

switch# show authentication sessions interface Gi1/0/12
Interface  MAC Address      Method  Status
Gi1/0/12   a4bb.6d12.3f09   dot1x   Authz Success
switch# show dot1x interface Gi1/0/12 details
  Oper control mode: auto
  PAE state: Authenticated

Devices that cannot run a supplicant need a separate decision, not a blanket exception. MAC authentication bypass, a registration portal or a dedicated device VLAN are all legitimate answers, but each one has to be chosen deliberately and documented. Write down which device classes may use the fallback and who approves them. An undocumented fallback is exactly how an unmanaged router ends up with a working VLAN and nobody's approval.

What you can see without decrypting

Encryption hides payloads, not behaviour. Source and destination addresses, ports, packet timing, flow volume and session duration stay visible at the boundary where you collect them, and that metadata is often enough to link an unfamiliar device to a port and an outbound destination. What you cannot read is the application inside the tunnel, and no amount of packet capture changes that without keys.

A persistent tunnel is not automatically malicious. Site-to-site links, backup agents and remote administration tools run continuously by design, so a flow that lasts all night proves nothing on its own. Compare it with the role assigned to that asset and with the approved baseline for its segment.

Scope egress on purpose. Allowing a destination port is not the same as approving the application that uses it, and a classifier's guess is not an authorization decision. Collect the metadata you need for the investigation, with a named owner and a retention window, rather than defaulting to full capture of every user's traffic.

Contain through the boundary you control

Before you isolate anything, confirm who owns the device and where it is attached. Then use the incident process to restrict the port or revoke the session, preserving the relevant logs while the evidence is still fresh. A switch port can be disabled and re-enabled; a production uplink that serves forty desks cannot be undone as easily.

Do not counterattack the endpoint and do not disable a shared port because a scan suggested a VPN protocol. Both actions interrupt legitimate work without improving the admission decision that let the device on in the first place.

The acceptance test is concrete: an approved endpoint still gets the access its role requires, and an unapproved device cannot obtain an equivalent path. Monitoring supports that boundary, and it does not need to break anyone's encryption to be worth the effort.