Tunnel establishment is not an application connectivity test
A VPN status describes the encrypted gateway relationship, not every host route and application port beyond it. An established tunnel can coexist with a missing route, a blocked destination or an absent return path. Begin with one intended source, destination, protocol and port instead of the broad statement that the VPN does not work.
Google's troubleshooting guidance distinguishes gateway negotiation from peer-network and host connectivity. The relevant route and selector behavior depends on the VPN design. Review whether the environment uses the applicable static or dynamic routing configuration before treating all tunnel types as interchangeable.
Prepare an explicit hybrid flow inventory
- Record both gateway owners, tunnel design, peer addresses and intended network ranges. Identify overlapping address ranges before building an application dependency on the path.
- Document route ownership, any applicable traffic selectors and host or network firewall requirements on both sides. Include the expected return path.
- Rehearse one approved application flow and one denied flow. Configure gateway and application evidence with a shared timestamp convention for cross-team troubleshooting.
For beginners, ping tests ICMP behavior where allowed. It does not prove that a database or HTTPS port is open. Pinging a gateway's public address also does not demonstrate that private host traffic crosses the tunnel.
Illustrative incident: the remote network has no return route
A cloud application sends a request to an on-premises service through the tunnel, but the peer network routes the reply elsewhere. The tunnel remains established while the application times out. This is an illustrative scenario. Repeatedly renegotiating the tunnel would interrupt working traffic without necessarily repairing the remote routing decision.
Follow the flow from hosts, not only gateways
Use the original failing client and a known listening destination where possible. Compare route selection, allowed application traffic and peer-side observations for the same test. Distinguish a request that never leaves its host from one that arrives at the destination but receives no permitted reply.
| Observation | Evidence | Investigation owner |
|---|---|---|
| Tunnel negotiation fails | Gateway logs and peer settings | Gateway teams |
| Tunnel is established, source has no route | Applicable routing decision | Source network owner |
| Request reaches destination, reply is absent | Return route and host firewall | Destination network owner |
| Small tests work, application still fails | Actual protocol and packet behavior | Application and network teams |
If selectors apply to the chosen design, compare their source and destination coverage on both sides. Do not change a shared secret as a first response to an application-port timeout when gateway negotiation is already successful.
Repair the demonstrated path and verify both directions
For the illustrative return-route fault, have the peer-network owner review the required destination prefix and routing policy. Preserve previous route configuration and assess other flows sharing that path. Avoid adding a broad default route merely to make one private service reachable.
Verify the original application operation, then test a representative return or independently initiated flow where the design allows it. Confirm the deliberately denied flow remains blocked. Observe reconnection and recovery through an approved non-production rehearsal so acceptance includes more than one lucky request during a quiet period.
Reliability objective and hybrid-network SOP
Measure successful end-to-end application transactions and path recovery, with tunnel metrics as supporting evidence. An illustrative internal objective could require every new hybrid route to pass source, destination and return-path acceptance before handover. It is an operating criterion, not a VPN SLA or a universal connectivity guarantee.
The SOP should retain flow tuple, gateway design, routes, applicable selectors, host evidence, peer owner and reversal trigger. Escalate uncertain address overlap or broad route changes before rollout. Keep both teams involved until application acceptance is complete; a green tunnel icon alone should not close the incident.
Clouvenix can scope related engineering support around a documented environment and agreed acceptance criteria.
Technical reference
Google Cloud: troubleshoot Cloud VPN. Reviewed 19 October 2026; confirm resource-specific prerequisites and behavior for the deployed configuration.