Prepare a Serial Recovery Path Before a GCE VPN Change

A second SSH window on the same interface is not a recovery path. It shares the route, the firewall rule and the daemon you are about to change, so it fails at exactly the moment you need it. Before editing VPN routes on a Compute Engine VM, prove three separate things: that you may use the serial console, that you can read its output, and that the guest will actually give you a login. The checks below run in that order, cheapest first, so a missing permission is discovered before it matters.

Step 1: confirm the cloud-side permission

Name the exact VM, project and zone, then check the organization's approved serial-access policy. The administrator needs the relevant permission, and interactive serial access has to be enabled for that instance under the project and organization controls in force.

Do not weaken an organization policy or switch console access on across a project to prepare one machine. Have the owner arrange the permitted mechanism before the experiment, not during the outage.

Step 2: prove you can read output

Reading serial output is the cheapest check, and it exercises the transport without touching the guest's login:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

Replace the identifiers and use the permitted port. Boot messages and console chatter tell you the channel works. They do not prove you can get a shell. That is why this step is separate from the next one.

Step 3: prove you can get an interactive login

The connection command opens a real session, not a preview:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

Treat it as a live console. Confirm the endpoint before typing credentials, because every keystroke lands on the instance.

This is where a plan that looked complete falls apart. Cloud permission is one boundary and the Linux login prompt is another, and passing the first tells you nothing about the second.

Step 4: prepare credentials the guest will accept

Google-provided Linux images do not enable local password-based login by default. A serial session can therefore reach a login prompt and stop there, waiting for a credential nobody set.

An approved recovery account, or whatever documented guest-login method your deployment uses, has to exist and be tested. An SSH key that works over the network does not automatically satisfy a console password prompt, so check the actual OS Login and key arrangement rather than assuming it covers this case.

Keep recovery credentials private. A root password pasted into a public startup-script example is a second incident waiting to happen.

Step 5: record the owner and the rollback

Before changing anything, preserve the working network configuration and write down who manages it, which VPN service is involved and how a rollback is performed. From a working session, capture the current routes, rules and service state.

That record is what turns a recovery channel into a repair, because the console only gets you a prompt. Write it before the change, not from memory afterwards. A rollback copied out of a wiki is not a rollback. It is a guess with a version number.

Step 6: verify after the change

An existing SSH session can survive a policy that blocks new ones, so test with a fresh normal administration session. Then test the VPN behavior you changed, separately.

Keep the recovery channel open until both checks pass, and close it according to the access policy afterwards. If SSH is already lost and no console login was prepared, stop treating serial access as a safety net and start the authorized account-recovery or instance-repair workflow. Standing up another VM as a jump host repairs neither the guest path nor the missing credentials.