> 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/productos/servers-2/how-to/ikev2-and-split-tunneling.md).
# Nuevas Mejoras de Configuración VPN: IKEV2 y Split Tunneling
Estas opciones del túnel te dan más control sobre la conexión: eliges la **versión de IKE** que se usa en la negociación y, cuando trabajas con varias redes remotas, decides si activas el **Split Tunneling**.
Todo desde el panel, sobre un túnel que ya tengas montado.
> #### 👍 Qué consigues
>
> Un túnel ajustado a tu topología y al equipo del otro extremo: con la versión de IKE adecuada y, si te interesa, una SA independiente por cada red remota.
### Antes de empezar
* Tener acceso al panel de Plenit con permisos sobre la suscripción de red.
* Tener un túnel VPN ya creado y operativo. Si aún no lo tienes, móntalo primero:[ Cómo crear un túnel VPN site-to-site.](/productos/servers/how-to/how-to-create-a-site-to-site-vpn-tunnel.md)
* Para Split Tunneling, haber declarado **al menos dos redes remotas** en el túnel.
### Paso 1. Configura la versión de IKE
La plataforma te deja elegir la versión de IKE que se usa al negociar el túnel:
* **IKEv1**: úsala solo si el equipo remoto no soporta v2.
* **IKEv2**: la recomendada, por compatibilidad, seguridad y estabilidad.
* **Automático**: la plataforma decide según quién inicia la conexión.
En modo automático, si **Plenit inicia** la conexión intenta IKEv2 por defecto (y puede no establecerse si el remoto solo acepta v1); si **Plenit responde** en modo pasivo, se adapta a la versión que proponga el origen.
Cuándo usar cada una: **IKEv2** si ambos extremos lo soportan; **IKEv1** solo si el remoto no admite v2; **Automático** si no controlas quién inicia siempre la conexión. Si en automático aparecen problemas, fija v1 o v2 de forma explícita.
> #### 🚧 Cambiar la versión renegocia el túnel
>
> Cambiar la versión de IKE obliga a renegociar la conexión. Programa el cambio en una ventana sin tráfico crítico.
### Paso 2. Activa el Split Tunneling
Cuando declaras varias redes remotas en un mismo túnel, el Split Tunneling hace que la plataforma cree una **SA (Security Association) independiente por cada red**, en lugar de agruparlas en una sola. Eso te da flexibilidad para adaptar la conexión al diseño de tu red y al comportamiento del equipo remoto.
En algunos entornos compensa una **única SA** (modo unificado); en otros, separar las redes (Split Tunneling). La decisión depende de tu topología y de las recomendaciones del fabricante del otro extremo.
{/\* 📸 CAPTURA 2 · control de Split Tunneling activado (visible con dos o más redes remotas) \*/}
| Modo | Qué hace | Cuándo encaja |
| --------------- | ---------------------------------------- | ------------------------------------------- |
| Unificado | Una sola SA para todas las redes remotas | El equipo remoto agrupa las redes en una SA |
| Split Tunneling | Una SA por cada red remota | Quieres gestionar cada red por separado |
#### Condiciones
* El control de Split Tunneling **solo aparece con dos o más redes remotas** configuradas.
* **Requiere IKEv2**: al activarlo, la plataforma ajusta la versión del túnel automáticamente.
* Si el extremo remoto trabaja con una SA única, el túnel sigue activo y funcional en **modo unificado**.
#### Compatibilidad entre fabricantes
Cada fabricante agrupa o separa las redes de forma distinta. Esto no es un problema de compatibilidad: Plenit te deja elegir el modo (unificado o Split Tunneling) para adaptarte a tu equipo. A modo de referencia:
### Verifica la configuración
Tras cambiar la versión de IKE o activar el Split Tunneling, confirma que el túnel sigue arriba y que cada red remota enruta. Desde un servidor de tu red local, haz `ping` a una IP de **cada** subred remota declarada:
```bash
ping
ping
```
Y comprueba que existe ruta hacia cada subred remota. En Linux:
```bash
ip route
```
En Windows, desde PowerShell:
```powershell
route print
```
Con Split Tunneling activo, cada red remota se valida por separado: si una responde y otra no, el problema está en esa red concreta, no en todo el túnel.
### Si algo no encaja
| Síntoma | Causa probable | Qué hacer |
| -------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------ |
| El túnel no levanta en modo Automático | El remoto solo acepta IKEv1 y Plenit intentó v2 | Fija IKEv1 de forma explícita |
| No aparece el control de Split Tunneling | Hay menos de dos redes remotas | Declara al menos dos redes remotas en el túnel |
| Al activar Split Tunneling cambió la versión | Split Tunneling requiere IKEv2 | Es el comportamiento esperado: ajusta la ventana de cambio |
| Una red remota no enruta y otra sí | SA o ruta de esa red mal configurada | Revisa esa subred concreta con `ping` y `ip route` / `route print` |
### Conclusión
Con estas opciones adaptas el túnel a la realidad del otro extremo: IKEv2 siempre que puedas, y Split Tunneling cuando quieras gestionar cada red remota por su cuenta.
La regla práctica es sencilla: prioriza IKEv2 por compatibilidad y estabilidad, y reserva el modo unificado para cuando el equipo remoto solo sepa trabajar con una SA.
---
# 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/productos/servers-2/how-to/ikev2-and-split-tunneling.md?ask=&goal=
```
`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.
