strongSwan es la implementación de IPsec de referencia en Linux. Negocia las claves con IKEv2 y deja el cifrado del tráfico al propio kernel (ESP), lo que lo hace compatible con routers y firewalls de casi cualquier fabricante. En este tutorial conectarás dos redes privadas con un túnel IPsec sitio a sitio entre dos gateways con Ubuntu 24.04, usando la interfaz moderna swanctl, primero con clave precompartida y después con certificados.
Requisitos previos
- Dos servidores con Ubuntu 24.04 LTS que actuarán como gateways, uno en cada sitio, cada uno con IP pública y acceso a su red local.
- Un usuario no root con privilegios
sudoen ambos. - Redes locales que no se solapen.
Esta guía usa el siguiente plan de direcciones:
| Dato | Sitio A | Sitio B |
|---|---|---|
| IP pública del gateway | 203.0.113.10 | 198.51.100.20 |
| Red local | 10.10.0.0/24 | 10.20.0.0/24 |
IP LAN del gateway (eth1) | 10.10.0.1 | 10.20.0.1 |
| Identidad IKE | site-a.example.com | site-b.example.com |
NotaSi solo necesitas unir dos servidores Linux y no hay un equipo de terceros que obligue a usar IPsec, WireGuard es más sencillo de configurar. IPsec es la opción adecuada cuando el otro extremo es un firewall comercial (Fortinet, Cisco, Palo Alto, un router en la nube) que solo habla IKEv2.
Paso 1: Instalar strongSwan con swanctl
Ubuntu ofrece dos formas de ejecutar strongSwan: la antigua, basada en ipsec.conf y el servicio strongswan-starter, y la actual, basada en swanctl.conf y el demonio charon-systemd. Esta guía usa la segunda. Instálala en los dos gateways:
sudo apt update
sudo apt install charon-systemd strongswan-swanctl strongswan-pki
strongswan-pki solo hace falta en el equipo donde generes los certificados (paso 6), pero no estorba en el resto.
Comprueba que el servicio está en marcha:
systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
Loaded: loaded (/usr/lib/systemd/system/strongswan.service; enabled; preset: enabled)
Active: active (running)
Si strongswan-starter estuviera también instalado y activo, desactívalo para que no compitan dos demonios por los puertos IKE:
sudo systemctl disable --now strongswan-starter
Paso 2: Activar el reenvío de paquetes
Cada gateway reenvía tráfico entre su LAN y el túnel. Activa el reenvío IPv4 en ambos:
sudo nano /etc/sysctl.d/99-ipsec.conf
net.ipv4.ip_forward = 1
sudo sysctl --system
sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
Paso 3: Configurar el túnel en el sitio A con clave precompartida
Los archivos de swanctl viven en /etc/swanctl/, y cualquier .conf dentro de /etc/swanctl/conf.d/ se carga automáticamente. Genera primero una clave precompartida larga y aleatoria:
openssl rand -base64 32
Crea la configuración en el gateway A:
sudo nano /etc/swanctl/conf.d/site-b.conf
connections {
site-b {
version = 2
local_addrs = 203.0.113.10
remote_addrs = 198.51.100.20
proposals = aes256gcm16-prfsha384-ecp384
dpd_delay = 30s
local {
auth = psk
id = site-a.example.com
}
remote {
auth = psk
id = site-b.example.com
}
children {
lan-a-lan-b {
local_ts = 10.10.0.0/24
remote_ts = 10.20.0.0/24
esp_proposals = aes256gcm16-ecp384
start_action = start
dpd_action = restart
}
}
}
}
secrets {
ike-site-b {
id-a = site-a.example.com
id-b = site-b.example.com
secret = "TU_CLAVE_PRECOMPARTIDA"
}
}
Sustituye TU_CLAVE_PRECOMPARTIDA por el valor generado. Los parámetros importantes:
proposalsyesp_proposals: algoritmos de la fase IKE y del tráfico ESP. Deben coincidir en ambos extremos. AES-GCM con curvas ECP de 384 bits es una combinación actual y soportada por la mayoría de equipos.local_tsyremote_ts: los selectores de tráfico, es decir, qué redes se cifran. Son la base de la política IPsec.start_action = start: inicia el túnel en cuanto se carga la configuración.dpd_delaycondpd_action = restartdetecta un extremo caído y renegocia.
Protege el archivo, porque contiene el secreto:
sudo chmod 600 /etc/swanctl/conf.d/site-b.conf
Paso 4: Configurar el sitio B
En el gateway B, crea el archivo equivalente con los papeles invertidos y la misma clave precompartida:
sudo nano /etc/swanctl/conf.d/site-a.conf
connections {
site-a {
version = 2
local_addrs = 198.51.100.20
remote_addrs = 203.0.113.10
proposals = aes256gcm16-prfsha384-ecp384
dpd_delay = 30s
local {
auth = psk
id = site-b.example.com
}
remote {
auth = psk
id = site-a.example.com
}
children {
lan-b-lan-a {
local_ts = 10.20.0.0/24
remote_ts = 10.10.0.0/24
esp_proposals = aes256gcm16-ecp384
start_action = start
dpd_action = restart
}
}
}
}
secrets {
ike-site-a {
id-a = site-a.example.com
id-b = site-b.example.com
secret = "TU_CLAVE_PRECOMPARTIDA"
}
}
sudo chmod 600 /etc/swanctl/conf.d/site-a.conf
Paso 5: Abrir el firewall y levantar el túnel
IKE usa UDP 500, y UDP 4500 cuando hay NAT de por medio (NAT-T). Sin NAT, el tráfico cifrado viaja como protocolo ESP (IP 50). En el gateway A, permite todo ello solo desde el gateway B:
sudo ufw allow from 198.51.100.20 to any port 500,4500 proto udp
sudo ufw allow proto esp from 198.51.100.20
UFW bloquea el tráfico reenviado por defecto, así que permite también el paso entre las dos LAN:
sudo ufw route allow from 10.20.0.0/24 to 10.10.0.0/24
sudo ufw route allow from 10.10.0.0/24 to 10.20.0.0/24
Repite en el gateway B cambiando la IP de origen por 203.0.113.10 (las reglas route son las mismas).
Carga la configuración y las claves en los dos gateways:
sudo swanctl --load-all
loaded ike secret 'ike-site-b'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'site-b'
successfully loaded 1 connections, 0 unloaded
Comprueba las asociaciones de seguridad (SA):
sudo swanctl --list-sas
site-b: #1, ESTABLISHED, IKEv2, 1a2b3c4d5e6f7a8b_i* 9c8d7e6f5a4b3c2d_r
local 'site-a.example.com' @ 203.0.113.10[500]
remote 'site-b.example.com' @ 198.51.100.20[500]
AES_GCM_16-256/PRF_HMAC_SHA2_384/ECP_384
established 42s ago, rekeying in 13950s
lan-a-lan-b: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 42s ago, rekeying in 3294s, expires in 3918s
in c1f2e3d4, 0 bytes, 0 packets
out c5b6a7d8, 0 bytes, 0 packets
local 10.10.0.0/24
remote 10.20.0.0/24
ESTABLISHED indica que la fase IKE ha terminado y INSTALLED que el kernel tiene la política IPsec para las dos redes. Si el túnel no se ha iniciado solo, fuérzalo:
sudo swanctl --initiate --child lan-a-lan-b
Paso 6: Comprobar el tráfico entre las redes
IPsec no crea una interfaz de red: el kernel cifra los paquetes que coinciden con la política. Por eso la prueba debe hacerse con direcciones que estén dentro de los selectores. Desde el gateway A, usa su IP LAN como origen:
ping -c 3 -I 10.10.0.1 10.20.0.1
Desde un equipo de la LAN A, haz ping a uno de la LAN B:
ping -c 3 10.20.0.50
Vuelve a mirar las SA: los contadores de bytes y paquetes deben haber subido.
sudo swanctl --list-sas
También puedes ver las políticas instaladas en el kernel:
sudo ip xfrm policy
Los equipos de cada LAN tienen que enviar el tráfico destinado a la red remota al gateway IPsec. Si el gateway no es su puerta de enlace predeterminada, añade en el router de la LAN una ruta estática (en el sitio A, 10.20.0.0/24 vía 10.10.0.1).
Paso 7: Usar certificados en lugar de clave precompartida
Con más de dos sitios, o si el otro extremo lo exige, los certificados son más seguros y fáciles de rotar que una clave compartida. Genera una pequeña CA en un equipo de confianza (puede ser uno de los gateways) con la herramienta pki de strongSwan:
mkdir -p ~/vpn-pki && cd ~/vpn-pki
umask 077
pki --gen --type ed25519 --outform pem > ca.key
pki --self --ca --lifetime 3652 --in ca.key --dn "CN=VPN CA" --outform pem > ca.crt
Crea una clave y un certificado para cada gateway. Para el sitio A:
pki --gen --type ed25519 --outform pem > site-a.key
pki --req --type priv --in site-a.key --dn "CN=site-a.example.com" --san site-a.example.com --outform pem > site-a.csr
pki --issue --cacert ca.crt --cakey ca.key --type pkcs10 --in site-a.csr --lifetime 1826 --outform pem > site-a.crt
Repite con site-b para el otro gateway. Comprueba el resultado:
pki --print --in site-a.crt
Copia los archivos a su sitio en cada gateway (en el A, ca.crt, site-a.crt y site-a.key):
sudo cp ca.crt /etc/swanctl/x509ca/
sudo cp site-a.crt /etc/swanctl/x509/
sudo cp site-a.key /etc/swanctl/private/
sudo chmod 600 /etc/swanctl/private/site-a.key
La clave de la CA (ca.key) no debe copiarse a los gateways. Guárdala fuera de línea.
Cambia los bloques local y remote de /etc/swanctl/conf.d/site-b.conf en el gateway A y elimina el bloque secrets:
local {
auth = pubkey
certs = site-a.crt
id = site-a.example.com
}
remote {
auth = pubkey
id = site-b.example.com
}
Haz el cambio equivalente en el gateway B (con site-b.crt en local) y recarga en ambos:
sudo swanctl --load-all
sudo swanctl --list-certs
La identidad remota debe coincidir con un SAN del certificado del otro extremo, y ese certificado debe estar firmado por la CA de /etc/swanctl/x509ca/. Vuelve a comprobar con sudo swanctl --list-sas que la SA se establece.
Solución de problemas
Los registros del demonio son la principal herramienta de diagnóstico:
sudo journalctl -u strongswan -f
NO_PROPOSAL_CHOSEN. Los algoritmos de proposals o esp_proposals no coinciden entre los dos extremos. Deja exactamente la misma cadena en ambos.
TS_UNACCEPTABLE. Los selectores no son simétricos: el local_ts de un lado debe ser el remote_ts del otro.
AUTHENTICATION_FAILED. Con PSK, el secreto o las identidades (id) no coinciden. Con certificados, la identidad no está en el SAN o falta la CA en x509ca.
La SA se establece pero no pasa tráfico. Revisa net.ipv4.ip_forward, las reglas ufw route y las rutas de los equipos de la LAN. Si el gateway hace NAT (masquerade) hacia Internet, esa regla puede estar traduciendo el tráfico entre LAN antes de que coincida con la política IPsec; excluye las redes remotas de la regla de NAT.
Conclusión
Tienes dos redes unidas por un túnel IPsec IKEv2 gestionado con swanctl, con autenticación por clave precompartida o por certificados de una CA propia. Como siguientes pasos, puedes añadir más children para publicar otras subredes, conectar un tercer sitio con su propio archivo en conf.d/ o sustituir el extremo remoto por un firewall comercial usando los mismos algoritmos.