Obtenido de: https://help.ubnt.com/hc/en-us/articles/360002668854

Descripción general

En este artículo, los usuarios encontrarán instrucciones sobre cómo verificar y solucionar problemas de VPNs IPsec creadas en el UniFi Controller. Este artículo cubrirá tanto Auto-IPsec como IPsec manual e involucra pasos tanto en la interfaz gráfica del UniFi Controller como en la línea de comandos (CLI) del USG.

| NOTAS Y REQUISITOS:

Aplicable a la línea de productos USG.
Este artículo requiere haber configurado al menos una VPN en Settings > Networks.
Si configuras una VPN manual, los protocolos, tiempos de vida y claves precompartidas deben coincidir en ambos extremos de la VPN.

---|---

Tabla de contenidos

Pasos: Cómo verificar la operación del túnel IPsec

(https://help.ubnt.com/hc/en-us/articles/360002668854#top)

Después de configurar la VPN en Settings > Networks y dejar que el USG se aprovisione, la VPN puede verificarse mediante varios métodos, descritos a continuación.

Sesión SSH en el USG

	CLI: Accede a la interfaz de línea de comandos (CLI) usando un programa como PuTTY. La salida que se imprime variará de lo que se muestra a continuación.

1. Verifica las Asociaciones de Seguridad (SAs) de IPsec y el estado en el USG:

**show vpn ipsec sa
** peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 184447c009d51f80:14cc0f13aff401c0
 local '203.0.113.1' @ 203.0.113.1
 remote '192.0.2.1' @ 192.0.2.1
 AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 established 237s ago, reauth in 85347s
 peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
 installed 237 ago, rekeying in 41939s, expires in 42964s
 in cb321982, 180 bytes, 3 packets, 231s ago
 out 5d4174b1, 180 bytes, 3 packets, 231s ago
 local 192.168.1.0/24
 remote 172.16.1.0/24

**sudo ipsec statusall
** Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
 uptime: 10 minutes, since Mar 12 09:05:48 2017
 malloc: sbrk 376832, mmap 0, used 269320, free 107512
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
 Listening IP addresses:
 203.0.113.1
 192.168.1.1
Connections:
peer-192.0.2.1-tunnel-1: 203.0.113.1...192.0.2.1 IKEv1
peer-192.0.2.1-tunnel-1: local:  uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: remote:  uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: child: 192.168.1.0/24 === 172.16.1.0/24 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-1{1}: ROUTED, TUNNEL
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-1: ESTABLISHED 5 minutes ago, 203.0.113.1...192.0.2.1
peer-192.0.2.1-tunnel-1: IKEv1 SPIs: 184447c009d51f80_i* 14cc0f13aff401c0_r, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-1: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-192.0.2.1-tunnel-1{1}: INSTALLED, TUNNEL, ESP SPIs: cb321982_i 5d4174b1_o
peer-192.0.2.1-tunnel-1{1}: AES_CBC_128/HMAC_MD5_96, 180 bytes_i (3 pkts, 324s ago), 180 bytes_o (3 pkts, 324s ago)
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24

2. Verifica la configuración de strongSwan de IPsec en el USG:

**sudo cat /etc/ipsec.conf
** # generated by /opt/vyatta/sbin/vpn-config.pl

config setup

conn %default
       keyexchange=ikev1

conn peer-192.0.2.1-tunnel-1
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.1.0/24
       ike=aes256-sha256-modp2048!
       keyexchange=ikev1
       ikelifetime=86400s
       esp=aes128-md5!
       keylife=43200s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       auto=route
       keyingtries=%forever
#conn peer-192.0.2.1-tunnel-1

3. Captura la llegada de tráfico IKE en la interfaz WAN externa del USG:

**sudo tcpdump -i eth0 -n udp dst port 500
** tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick

	Nota : Esta es una captura en vivo. Si no hay salida, significa que el tráfico no se está generando en el cliente, o algo está bloqueando el tráfico en una etapa anterior.

4. Captura los registros de la VPN IPsec del USG:

**sudo swanctl --log
** creating acquire job for policy 192.168.1.10/32 === 172.16.1.10/32 with reqid {1}
 initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1 to 192.0.2.1
 generating ID_PROT request 0
 sending packet: from 203.0.113.1 to 192.0.2.1 (160 bytes)
 received packet: from 192.0.2.1 to 203.0.113.1 (108 bytes)
 parsed ID_PROT response 0
 received NAT-T (RFC 3947) vendor ID
 generating ID_PROT request 0
 parsed ID_PROT response 0
 generating ID_PROT request 0
 parsed ID_PROT response 0
 IKE_SA peer-192.0.2.1-tunnel-1 established between 203.0.113.1...192.0.2.1
 generating QUICK_MODE request 561157166
 parsed QUICK_MODE response 561157166
 CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb321982_i 5d4174b1_o and TS 192.168.1.0/24 === 172.16.1.0/24

| Nota : Esta también es una captura en vivo. Si no hay salida, significa que el tráfico no está siendo permitido a través del firewall. Alternativamente, usa el comando show vpn log | no-more para ver el historial completo de registros de IPsec. ---|---

5. Envía tráfico a través del túnel desde un cliente en un lado del túnel VPN a otro cliente. No pruebes esto desde un USG. El tráfico debe provenir de un cliente LAN.

6. Para forzar la conexión a iniciarse sin tener que enviar tráfico primero a través del túnel, ejecuta los siguientes comandos:

sudo ipsec statusall

Bajo la lista de Connections debería estar el nombre de los peers. El nombre del peer variará de un USG a otro.

Ejemplo:

**Connections:
 peer-172.20.1.13-tunnel-vti**: 172.20.1.242...172.20.1.13 IKEv1, dpddelay=20s
**peer-172.20.1.13-tunnel-vti** : local:  uses pre-shared key authentication
**peer-172.20.1.13-tunnel-vti** : remote:  uses pre-shared key authentication
**peer-172.20.1.13-tunnel-vti** : child: 0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart

Procede a forzar la conexión del túnel con el siguiente comando:

sudo ipsec up <connection_name>

Ejemplo:

**user@ubnt:~$ sudo ipsec up peer-172.20.1.13-tunnel-vti**
 generating QUICK_MODE request 1747091534
sending packet: from 172.20.1.242 to 172.20.1.13 (460 bytes)
received packet: from 172.20.1.13 to 172.20.1.242 (460 bytes)
parsed QUICK_MODE response 1747091534
CHILD_SA peer-172.20.1.13-tunnel-vti{1} established with SPIs cc5c8c8e_i c9473648_o and TS 0.0.0.0/0 === 0.0.0.0/0
connection 'peer-172.20.1.13-tunnel-vti' established successfully
adipple@ubnt:~$ show vpn ipsec sa
peer-172.20.1.13-tunnel-vti: #6, ESTABLISHED, IKEv1, 5366e644f90cde04:ef0e999fc18e24e7
 local '172.20.1.242' @ 172.20.1.242
 remote '172.20.1.13' @ 172.20.1.13
 AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 established 4131s ago, reauth in 23759s
 peer-172.20.1.13-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128/MODP_2048
 installed 881 ago, rekeying in 1766s, expires in 2720s
 in c0296e69, 0 bytes, 0 packets
 out c77e1590, 0 bytes, 0 packets
 local 0.0.0.0/0
 remote 0.0.0.0/0
 peer-172.20.1.13-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128/MODP_2048
 installed 14 ago, rekeying in 2837s, expires in 3587s
 in cc5c8c8e, 0 bytes, 0 packets
 out c9473648, 0 bytes, 0 packets
 local 0.0.0.0/0
 remote 0.0.0.0/0

Esta salida indica que el túnel se levantó exitosamente.

Solución de problemas

(https://help.ubnt.com/hc/en-us/articles/360002668854#top)

Problemas con ICMP o acceso a clientes/redes remotas

Si la dirección de la interfaz WAN del USG está detrás de NAT, lo que significa que la dirección IP se encuentra dentro de RFC1918 (direcciones IPv4 privadas), necesitarás hacer port forward de los puertos UDP 500 y 4500 en el router o módem anterior al USG. Para la “IP WAN local” en la configuración VPN de UniFi, ingresa la dirección WAN del USG (incluso si está detrás de NAT), luego procede conectándote por SSH al USG y escribiendo:

configure
set vpn ipsec site-to-site peer x.x.x.x authentication id <public_ip_of_modem or upstream router>

Esto se debe a que el USG anunciará su dirección privada como su ID, mientras que el lado remoto esperará la dirección pública.

	Nota : Para hacer este cambio persistente, consulta el siguiente artículo. (https://help.ubnt.com/hc/en-us/articles/215458888)

Túnel activo, sin respuesta ICMP:

Si el túnel está activo pero no puedes hacer ping a través de él, escribe show vpn ipsec sa y observa los paquetes de entrada/salida. Si ves paquetes de “salida” pero no de “entrada”, eso significa que ESP podría estar siendo filtrado por el módem anterior. Puedes intentar configurar: set vpn ipsec site-to-site peer x.x.x.x force-encapsulation enable

Esto encapsula ESP (encapsulating security payload) dentro de UDP 4500 con NAT-T 2. Si el túnel está activo, pero no puedes hacer ping, verifica si el tráfico está pasando. Origina un ping desde un cliente real en la LAN (no desde el USG en sí) destinado a un cliente en la LAN remota a través de la VPN. Si tu VPN tiene “enable dynamic routing” configurado (o es “auto”), es una VPN basada en rutas aprovisionada con VTI. Puedes ver esto en “show ip route”

Para ver si el tráfico está atravesando el túnel, ejecuta estos comandos en el USG mientras envías un ping a un cliente remoto:

sudo tcpdump -npi vti0 (si usas **Auto IPsec VPN**)
sudo tcpdump -npi vti64 (si es **VPN manual** con enrutamiento dinámico habilitado)

Observa los contadores de paquetes de entrada/salida con “show vpn ipsec sa”, para ver si alguno está pasando. Paquetes de salida significa que el USG los está enviando a través del túnel, paquetes de entrada significa que los está recibiendo.

Descripción general

Tabla de contenidos

Pasos: Cómo verificar la operación del túnel IPsec

Sesión SSH en el USG

Solución de problemas

Problemas con ICMP o acceso a clientes/redes remotas

Túnel activo, sin respuesta ICMP:

Para ver si el tráfico está atravesando el túnel, ejecuta estos comandos en el USG mientras envías un ping a un cliente remoto:

Artículos Relacionados

Unifi USG: Solución de problemas de autenticación RADIUS

Cómo redirect online domain/corporate traffic on a Windows 8 VPN connection

Configurar Servidor OpenVPN en Ubuntu