> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/docs-en/productos/servers-2/how-to/how-to-create-a-site-to-site-vpn-tunnel.md).

# How to Create a site-to-site VPN Tunnel

A site-to-site VPN connects two private networks over the Internet as if they were on the same local network, with end-to-end encrypted traffic.

In this tutorial you create the full tunnel between two **VPC** hosted in Plenit, configuring the **two** ends.

> #### 👍 What you get
>
> An operational IPsec tunnel between two VPCs, with one end as a passive connection and the other as an active one, securely communicating their subnets.

### How the tunnel works

The tunnel has two ends. One is configured as **passive connection** (waits for the other to start the negotiation) and the other as **active connection** (it starts it). Both share an **IPsec key** that authenticates them. The golden rule is symmetry: what is "remote" on one end is "local" on the other.

| Field                 | End 1 (ext1)                 | End 2 (ext2)             |
| --------------------- | ---------------------------- | ------------------------ |
| VPC and local network | VPC1 / TIER1                 | VPC2 / TIER2             |
| Remote gateway        | VPC2 IP                      | VPC1 IP                  |
| Remote network        | TIER2 subnet                 | TIER1 subnet             |
| Role                  | Passive connection           | Active connection        |
| IPsec key             | It is generated when created | The saved one is entered |

> #### ❗️ Save the IPsec key from the first end
>
> When creating the first end, the platform generates the IPsec key. Copy it and save it: you will need it exactly as is when configuring the second end, and it is what authenticates the tunnel.

### Scenarios

| Scenario                                         | What you configure in Plenit                        |
| ------------------------------------------------ | --------------------------------------------------- |
| VPC1 and VPC2, both in Plenit                    | Both ends (double process)                          |
| VPC1 in Plenit, VPC2 with another cloud provider | Only ext1; the other side, with the provider's tool |
| VPC1 in Plenit, a router at the other end        | Only ext1; the other side, on the router            |

This tutorial covers the first scenario, with both VPCs in Plenit.

### Before you start

* Have a **Servers** active.
* Have both **VPC** created with their TIERs. If you don't have them, create them first:[ How to create a VPC and associate a TIER.](/docs-en/productos/servers/how-to/how-to-create-a-vpc-and-associate-a-tier.md)
* Locate the gateways and subnets in **Networks/IP → VPC Networks**: you need them during setup.

***

### First end (ext1 → ext2)

#### Step 1. Access the Servers subscription

Go to the subscription of **Servers** from its card.

{/\* 📸 SCREENSHOT 1 · Servers subscription card \*/}

![Access to the Servers subscription](https://REEMPLAZA-URL/servidores-howto-vpn-01.png)

#### Step 2. Start creating the tunnel

In the side menu, open **VPN** and click **Create Site-to-Site Tunnel**.

{/\* 📸 SCREENSHOT 2 · VPN subsection with the Create Site-to-Site Tunnel button \*/}

![VPN subsection with the option to create a site-to-site tunnel](https://REEMPLAZA-URL/servidores-howto-vpn-02.png)

#### Step 3. Name the VPN and configure the remote network

1. Assign a **name** to this connection, for example `VPN1`.
2. In **Gateway**, enter the IP of the remote gateway of ext2 (the **VPC2 IP**).
3. In **Remote Network**, indicate the subnet of the **TIER2**.

{/\* 📸 SCREENSHOT 3 · Name, Gateway, and Remote Network fields \*/}

![Name and remote network configuration of the first end](https://REEMPLAZA-URL/servidores-howto-vpn-03.png)

#### Step 4. Configure the tunnel

The default values work for this scenario; keep them unless your network policy requires others.

> #### 📘 About tunnel parameters
>
> Negotiation supports IKEv1, IKEv2, or automatic mode. 
>
> If you connect to multiple remote networks, one association is created per network (split tunneling). 
>
> A single gateway supports up to ten VPN tunnels.

#### Step 5. Configure the local network and create the end

1. Choose the **VPC associated with the local network** (`VPC1`) and the **local network** (`TIER1`).
2. Mark this end as **passive connection**.
3. Create this first part of the VPN.

When created, the platform shows the **IPsec key**. Save it: you will use it on the second end.

{/\* 📸 SCREENSHOT 4 · local network with passive connection checked and the generated IPsec key \*/}

![Local network configuration as passive connection and the IPsec key](https://REEMPLAZA-URL/servidores-howto-vpn-04.png)

***

### Second end (ext2 → ext1)

#### Step 6. Create a new VPN

In the subsection **VPN**, click **New Site-to-Site VPN** to configure the reverse path.

#### Step 7. Name the second VPN and configure the remote network

1. Name this connection, for example `VPN2`.
2. In **Gateway**, enter the IP of the remote gateway of ext1 (the **VPC1 IP**).
3. In **Remote Network**, indicate the subnet of the **TIER1**.

{/\* 📸 SCREENSHOT 5 · fields of the second end, reversed relative to the first \*/}

![Name and remote network configuration of the second end](https://REEMPLAZA-URL/servidores-howto-vpn-05.png)

#### Step 8. Configure the tunnel of the second end

Keep the default values, just like in Step 4. The difference is that here **you enter the IPsec key** that you saved when creating the first end.

#### Step 9. Configure the local network and create the VPN

1. Choose the **VPC associated with the local network** (`VPC2`) and the **local network** (`TIER2`).
2. Leave **unchecked** the passive connection, so that this end remains as **active connection**.
3. Click **Create VPN**.

With this, the tunnel between the two ends is created.

{/\* 📸 SCREENSHOT 6 · local network of the second end as active connection and the tunnel created \*/}

![Second end configured as active connection](https://REEMPLAZA-URL/servidores-howto-vpn-06.png)

### Verify the tunnel

In the panel, in the subsection **VPN**, confirm that the **two** connections exist, one from ext1 and another from ext2, and that one appears as **passive** and the other as **active**.

The real test is whether the traffic passes through. From a TIER1 server, run `ping` to a TIER2 server (and vice versa). Remember that in Windows you must allow incoming ICMP on the destination.

```bash
ping <IP-OF-A-SERVER-ON-THE-OTHER-END>
```

Check that the route to the remote subnet goes through the tunnel. On Linux:

```bash
ip route
traceroute <REMOTE-IP>
```

In Windows, from PowerShell:

```powershell
route print
tracert <REMOTE-IP>
```

### If something does not fit

| Symptom                                        | Likely cause                                 | What to do                                                                 |
| ---------------------------------------------- | -------------------------------------------- | -------------------------------------------------------------------------- |
| The tunnel doesn't come up                     | The IPsec key does not match on both ends    | Enter the key generated in ext1 again in ext2                              |
| The two ends do not negotiate                  | Both ended up passive or both active         | Leave one passive and the other active                                     |
| No traffic passes even though the tunnel is up | Remote and local network reversed on one end | Check the symmetry table: what is remote on one side is local on the other |
| The ping fails only against Windows            | The firewall blocks incoming ICMP            | Allow ICMPv4 on the destination server                                     |

### Conclusion

With both ends properly configured, you have a working site-to-site VPN that connects the two VPCs securely over the Internet.&#x20;

The whole procedure rests on two ideas: symmetry (what is remote on one side is local on the other) and the shared IPsec key.&#x20;

If both are right, the tunnel comes up; if something doesn't work, it's almost always one of those two.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.plenit.com/docs-en/productos/servers-2/how-to/how-to-create-a-site-to-site-vpn-tunnel.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.