Enable IP forwarding on an existing GCE VPN gateway

The VM was created without IP forwarding, it already runs the VPN software, and the instinct is to rebuild it from the template with the flag set. That rebuild is unnecessary. Compute Engine exposes canIpForward as an updatable property, and the documented update path applies it with a refresh rather than a restart. What the flag actually controls is narrow: without it, the platform drops packets that arrive at the instance but are not addressed to the instance's own address. A gateway forwarding other machines' traffic does exactly that, so the flag has to be on. Everything after that is guest configuration and routing, which the flag does not touch.

What the flag permits, and what it does not

With forwarding disabled, the platform treats the instance as an endpoint. Packets whose destination is the instance's own address are delivered; packets the instance is supposed to pass along on behalf of someone else are not.

With forwarding enabled, the instance may act as a next hop for a VPC route, which is the role a VPN appliance needs. The flag says nothing about firewalls, guest routing, tunnel configuration or return paths, and a true value on a broken gateway is still a broken gateway.

Read the current property

Inspect the setting before changing anything, using a read-only describe against the intended instance, project and zone:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

A false value matters only if this VM is meant to be a next hop. If it is, the rest of the path still has to be checked separately, because the property is one line in a longer chain.

Update the existing instance

Google's instance-property update procedure exports the current resource, modifies the property and submits the result. That is a different workflow from the creation-time --can-ip-forward flag, and it is the one that works on a running VM.

Export the definition to a local file first, and keep an unchanged copy for comparison:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

In that exported file, set the property and change nothing else:

canIpForward: true

Retain the whole resource, including its fingerprint. Replacing the file with a one-line YAML document, or bundling unrelated machine-type, disk or interface edits into the same submission, is how a property change becomes an outage.

Ask the update mechanism to validate the file and report what it would require, before any effective change is permitted:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

That validation run does not enable forwarding. Read the response for invalid properties and for the action it says is needed. For this isolated change the documented action is REFRESH. If the result asks for a restart, the file contains more than the property you meant to change, so inspect it instead of granting the restart.

Apply the reviewed file with the refresh limit:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Check that the operation completed and run the describe command again. If the fingerprint no longer matches, someone else changed the instance while you were editing, so export a fresh copy and review the change again rather than forcing your stale file through.

The guest still has to route the packet

Cloud permission does not make the appliance a router. Confirm that a VPC route selects this VM as the next hop for the destination prefix, and that the guest routes between the tunnel and the right interface with its own forwarding policy enabled.

Firewall policy has to permit the inner flow as well as the outer listener. Opening only the VPN port describes the encrypted transport and says nothing about the application exchange inside it.

Finally, the destination needs a return path to the client pool, or the design has to translate sources deliberately. If the destination sees translated traffic, check the translated source; if the design preserves the pool, check that pool in the return route and the access rules. Adding NAT before deciding which design you want hides a missing route and changes the policy the destination sees.

On a Linux gateway, kernel forwarding is part of the guest configuration. A pfSense appliance has its own equivalent, and copying a Linux sysctl command into it is not the matching step.

Verify from the client that needs access

Test from a VPN client to one target service, not from the gateway itself. A connection initiated on the gateway uses a different source and never exercises the forwarding rules you just enabled.

Record the property in whatever manages the appliance. A manually corrected VM works until its next replacement quietly reintroduces the original setting, and that failure will look like a regression in the VPN software.

Order of work: read the property, export and edit one line, validate with NO_EFFECT, apply with REFRESH, confirm the guest forwards, then test from a client.