Services, policies, endpoint groups, and site connections
Understand the five VPN objects, the values each accepts, how they're shared, what their statuses mean, and which settings the peer device needs.
A site-to-site tunnel is built from five objects. Each one is a resource of its own, listed on its own tab under NetworkingVPN. This article describes what each object sets and the values it accepts, how objects are shared, what their statuses mean, and which settings the device at the other end of the tunnel needs.
The five objects
| Object | Tab | What it sets | Can several connections use it? |
|---|---|---|---|
| VPN service | VPN services | The router that the tunnels end on. | Yes |
| IKE policy | IKE policies | Phase 1: how the gateways authenticate each other and agree on keys. | Yes |
| IPsec policy | IPsec policies | Phase 2: how the traffic inside the tunnel is protected. | Yes |
| Endpoint group | Endpoint groups | One end of a tunnel: local subnets, or remote CIDRs. | Yes |
| Site connection | Site connections | The tunnel to one peer gateway. | No; it's the object that uses the others. |
A site connection refers to one VPN service, one IKE policy, one IPsec policy, and two endpoint groups: a local one and a peer one. It doesn't copy them.
VPN services
A VPN service anchors tunnels on one router of the project.
- Router. It must have an external gateway; the console lists only such routers. The router can't be changed after the service is created.
- External address. The router's external gateway address, as the provider reports it. It's the local end of the tunnels and the address that the peer device connects to. Until the provider reports it, the console shows Not reported yet.
- Status. The provider keeps a new VPN service at Pending create until the first site connection uses it. See Statuses.
One VPN service can carry many site connections. You can rename it and change its description while it's in use, but you can't delete it until no site connection uses it.
IKE policies
An IKE policy sets phase 1 of the tunnel.
| Field | Values | Default |
|---|---|---|
| IKE version | v1, v2 | v2 |
| Phase 1 negotiation mode | main, aggressive | main |
| Authentication algorithm | sha1, sha256, sha384, sha512, aes-xcbc, aes-cmac | sha256 |
| Encryption algorithm | 3des, aes-128, aes-192, aes-256, and the CCM and GCM variants of AES-128, AES-192, and AES-256 with 8-, 12-, and 16-byte ICVs, such as aes-128-ccm-8 or aes-256-gcm-16 | aes-256 |
| PFS group | group2, group5, and group14 to group31 | group14 |
| Lifetime (seconds) | At least 60 | 3600 |
On an IKE policy, PFS group is the Diffie-Hellman group of the phase 1 key exchange. Lifetimes are always in seconds.
IPsec policies
An IPsec policy sets phase 2 of the tunnel.
| Field | Values | Default |
|---|---|---|
| Transform protocol | esp, ah, ah-esp | esp |
| Encapsulation mode | tunnel, transport | tunnel |
| Authentication algorithm | The same values as for an IKE policy | sha256 |
| Encryption algorithm | The same values as for an IKE policy | aes-256 |
| PFS group | The same values as for an IKE policy | group14 |
| Lifetime (seconds) | At least 60 | 3600 |
On an IPsec policy, PFS group is the Diffie-Hellman group used when the phase 2 keys are renewed.
The values in both tables are the ones that the platform accepts. Choose values that the peer device supports too. For the values that keep the traffic encrypted, see VPN tunnels.
Endpoint groups
An endpoint group names one end of a tunnel.
| Type | End | Endpoints |
|---|---|---|
| subnet (local end) | Local | One or more subnets of the project. |
| cidr (remote end) | Remote | One or more CIDRs, such as 172.16.0.0/16. In the console, separate them with commas, spaces, or semicolons. |
- A group lists each subnet or CIDR only once.
- The type and the endpoints can't be changed after the group is created. You can change its name and description.
- A site connection needs a subnet (local end) group as its local group and a cidr (remote end) group as its peer group. Every subnet in the local group must be attached to the router of the connection's VPN service.
Put every local subnet that should reach a peer into one group. A second site connection between the same two gateways doesn't work: the two gateways run a single IKE session, the provider refuses the second tunnel, and that connection carries no traffic although it shows a tunnel status. The platform doesn't stop you from creating it.
Site connections
A site connection is the tunnel between your VPN service and one peer gateway.
| Field | Rules | Default | Change later? |
|---|---|---|---|
| Name | 1–255 characters, unique among the project's site connections. | — | Yes |
| VPN service, IKE policy, IPsec policy | Existing objects in the project, finished creating. | — | No |
| Local endpoint group, Peer endpoint group | A subnet group and a CIDR group, as described under Endpoint groups. | — | No |
| Peer gateway address | The public address of the remote VPN device. | — | To change the peer address, create a new connection and delete the old one. |
| Pre-shared key | At least 8 characters. It can't be read back. You can only replace it. | — | Yes: enter a new key. Changing it renegotiates the tunnel. |
| Initiator | bi-directional or response-only. With response-only, this side waits for the peer to start the negotiation. | bi-directional | Yes |
| Dead peer detection action | hold, clear, disabled, restart, or restart-by-peer: what the gateway does when dead peer detection finds the peer unresponsive. | hold | Yes |
| DPD interval (seconds) | At least 1. | 30 | Yes |
| DPD timeout (seconds) | At least 2, and greater than the interval. | 120 | Yes |
| MTU | At least 68, and at most the deployment's tenant network MTU. | The console offers the smallest MTU of the project's networks. Without a value, the API uses the deployment's tenant network MTU. | Yes |
To change a connection, disable or restart its tunnel, or delete it, see Edit, disable, and delete VPN objects.
IKE identities. The IKE identities are always the two gateway addresses; you can't set them. The VPN service's external address identifies this side, and the peer gateway address identifies the peer.
MTU. The MTU is the tunnel's own. The packets that fit inside it are smaller, because ESP adds a header, a trailer, and authentication data to every packet. A workload sized for the full network MTU must lower its own MTU or clamp its TCP MSS. Packets that are too large fail with an error instead of disappearing.
Reuse and changes
VPN services, policies, and endpoint groups are shared. The Used by column counts the site connections that use each one. While the count is above 0, the object can't be deleted, and an IKE or IPsec policy can't be changed at all, not even renamed. A VPN service or an endpoint group can still be renamed.
A site connection keeps its VPN service, its policies, and its endpoint groups for its whole life. The provider doesn't let the service or the policies change, and the platform doesn't let the endpoint groups change. To use other objects, create a new site connection and delete the old one.
For the steps, see Edit, disable, and delete VPN objects.
Statuses
Every VPN object has a provisioning status, shown in the Provisioning column:
| Status | What it means |
|---|---|
| Pending create, Pending update, Pending delete | The platform is creating, changing, or deleting the object. |
| Ready | The object exists at the provider with the settings shown. |
| Error | The last create, change, or deletion failed, or, for a site connection, the provider reports the connection in error. The object's details show What the provider reported with the reason. |
VPN services and site connections also have a Status: the provider's own status, recorded as the provider reported it. It's Active, Down, Inactive, Error, or a pending state, and Not reported yet until the provider has reported one. For a site connection, this is the tunnel status. Active means that the tunnel's security associations are established. It doesn't prove that traffic passes; test that with traffic between the two networks.
The platform records the status when it finishes an operation on the object. For a site connection, that's creating it, changing its configuration, or enabling, disabling, or restarting it; a VPN service's status is read again when a site connection on it finishes creating. The platform also reads the project's VPN objects from the provider at regular intervals and records what the provider reports, except for an object with an operation in progress. Refresh on a connection's page reloads the connection's record from the platform; it doesn't make the platform ask the provider.
Configure the peer device
The device at the other end of the tunnel needs settings that match the site connection. Find each value in the console as follows. The policies and endpoint groups open from the References panel on the connection's page.
| Setting on the peer device | Value | Where to find it |
|---|---|---|
| Remote gateway address | The VPN service's external address. | External address on the VPN services tab |
| Its own gateway address and IKE identity | The address that you entered as the peer gateway address. | Peer gateway and Peer ID on the connection's page |
| Remote IKE identity | The VPN service's external address. | External address on the VPN services tab |
| Authentication | The pre-shared key. | The key you entered; it can't be read back. |
| IKE version and phase 1 mode | IKE version, Phase 1 negotiation mode | IKE policy |
| Phase 1 encryption and integrity | Encryption algorithm, Authentication algorithm | IKE policy |
| Phase 1 Diffie-Hellman group | PFS group | IKE policy |
| Phase 1 lifetime | Lifetime (seconds) | IKE policy |
| Phase 2 protocol and mode | Transform protocol, Encapsulation mode | IPsec policy |
| Phase 2 encryption and integrity | Encryption algorithm, Authentication algorithm | IPsec policy |
| Phase 2 PFS group | PFS group | IPsec policy |
| Phase 2 lifetime | Lifetime (seconds) | IPsec policy |
| Its own networks | The CIDRs of the peer endpoint group. | Peer endpoint group |
| Remote networks | The CIDRs of the subnets in the local endpoint group. | Local endpoint group |
| Who starts the negotiation | If Initiator is response-only, the peer must start it. | Initiator on the connection's page |