​
Overview

This screen lists the VPN gateways across all your VPCs. A VPN gateway is the Simnet-side endpoint of a tunnel; the far side is a customer gateway.
Navigation: Networking → Site-to-Site VPN. Titled Site-to-Site VPN, subtitled “VPN gateways across all VPCs”.

​
An inventory, not a workbench

This screen has no create button, no filters, and one row action. It’s a read-mostly inventory of gateways that exist across your VPCs.Gateways are created from the VPC that owns them — the empty state says so: “Create a VPN gateway from a VPC’s VPN Gateway tab.” See VPC.

​
The pieces of a working tunnel

Three objects, created in order, in three different places:
Confusion about which screen does what is the usual reason this feels harder than it is. This screen only lists gateways. Everything you create lives in the VPC’s own tabs, except the customer gateway.

​
Columns

Expanding a row reveals the Gateway ID and VPC ID — useful when correlating with API responses or a support request. Search matches IP and VPC.
The status dot is always green. It indicates the gateway exists, not that any tunnel through it is up. For tunnel state, check the VPC’s VPN Connections tab.

​
Row actions

One: Delete.
Deletion asks for confirmation and spells out the blast radius, including the Fabric warning below.Deleting a gateway breaks every VPN connection built on it. Check the VPC’s VPN Connections tab first.

​
Fabric uses these too

Fabric connections are managed site-to-site VPN links, so they’re built on the same VPN gateway each zone received when it was deployed.
Do not manually delete a VPN gateway that Fabric is using. Fabric manages its own links, and removing the underlying gateway from here will break them without Fabric knowing why. Disconnect Fabric links from the Fabric screen instead.

​
How a tunnel comes up

Once the three objects exist, the two gateways negotiate with each other in two phases. Knowing which phase failed is most of the diagnosis.
Neither phase reports a useful error to the console. A tunnel that never leaves its initial state has almost always failed phase 1, and the platform can’t tell you why — the remote end simply stops answering.

​
Worked example: reach an on-premises database

1

Check for CIDR overlap before anything else

Your VPC and the remote network must not overlap. A VPC on 10.0.0.0/16 cannot reach a remote 10.0.0.0/24. Neither range can be changed later, so this decision comes first.
2

Create the VPN gateway in the VPC

Open the VPC → VPN Gateway tab → create one. It then appears on this screen with its public address.
3

Note that address for the remote side

Whoever configures the remote device needs this address as their peer.
4

Define the customer gateway

Networking → Customer Gateways → Add Gateway, with the remote device’s public IP, the networks behind it, and a matching pre-shared key.
5

Create the connection

Back in the VPC → VPN Connections tab → create a connection joining your VPN gateway to that customer gateway.
6

Allow the traffic

The tunnel is a path, not permission. Add ingress rules for the remote range and egress rules for the replies — firewall policies are stateless, so both are needed.
7

Verify in both directions

One direction working and the other failing is nearly always a missing firewall rule, not a tunnel fault.
When a tunnel won’t establish at all, the cause is almost always on the parameters rather than the platform: a mismatched pre-shared key, or IKE and ESP proposals with no overlap. Compare both ends against one source of truth before investigating anything else.

​
Empty and error states

If loading fails, this screen keeps whatever it last showed rather than displaying an error. A stale list is possible — use the search box or reload if the contents look wrong.

Customer Gateways

The remote end, and its parameters.

VPC

Where gateways and connections are created.

Fabric

Managed links between Simnet VPCs.

Firewall Policies

Allowing traffic through an established tunnel.