Obtained from: https://help.ubnt.com/hc/en-us/articles/360002668854

Overview

In this article, users will find instructions on how to verify and troubleshoot IPsec VPNs created in the UniFi Controller. This article will cover both Auto-IPsec and manual IPsec and involves steps both in the UniFi Controller GUI, and USG command line (CLI).

| NOTES & REQUIREMENTS:

  • Applicable to the USG lineup.
  • This article has the requirement of configuring at least one VPN under Settings >Networks.
  • If configuring a manual VPN, Protocols, lifetimes, and pre-shared keys must match on both VPN endpoints.

---|---

Table of Contents

  1. (https://help.ubnt.com/hc/en-us/articles/360002668854#3)
  2. (https://help.ubnt.com/hc/en-us/articles/360002668854#4)
  3. (https://help.ubnt.com/hc/en-us/articles/360002668854#5)

Steps: How to Verify IPsec Tunnel Operation

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

After configuring the VPN under Settings >Networks and letting the USG provision, the VPN can be verified by several methods, described below.

SSH Session on the USG

CLI: Access the command line interface (CLI) by using a program such as PuTTY. The output that is printed will vary from what is shown below.

1. Verify the IPsec Security Associations (SAs) and status on the 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. Verify the USG IPsec strongSwan configuration:

**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. Capture the arrival of IKE traffic on the USG external WAN interface:

**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
Note : This is a live capture. If there is no output that means that the traffic is either not being generated on the client, or there is something blocking the traffic upstream.

4. Capture the USG IPsec VPN logs:

**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

| Note : This is also live capture. If there is no output that means that the traffic is either not being allowed through the firewall. Alternatively, use the show vpn log | no-more command to view the entire IPsec log history.
---|---

5. Send traffic over the tunnel from a client on one side of the VPN tunnel to another client. Do not test this from a USG. The traffic must come from a LAN client.

6. To force the connection to start without first having to send traffic over the tunnel execute the following commands:

sudo ipsec statusall

Under the Connections list should be the name of the peers. The name of the peer will vary from USG to USG.

Example:

**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

Proceed by forcing the tunnel to connect with the following command:

sudo ipsec up <connection_name>

Example:

**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

This output indicates that the tunnel was successfully brought up.

Troubleshooting

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

Problems with ICMP or Accessing Remote Clients/Networks

If the USG WAN interface address is behind NAT, which means the IP address lies within RFC1918 (Private IPv4 addresses) you will need to port forward UDP ports 500 and 4500 on the router or modem upstream of the USG. For the “local WAN IP” in the VPN configuration of UniFi, put the USG’s WAN address (even if behind NAT), then proceed with SSHing into the USG and typing:

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

This is because the USG will advertise it’s private address as its ID, while the remote side will be expecting the public address.

Note : To make this change persistent please see the following article. (https://help.ubnt.com/hc/en-us/articles/215458888)

Tunnel Up, No ICMP Reply:

  1. If the tunnel is up but can’t ping across, type show vpn ipsec sa and look at the packets in/out. If you see “out” packets but not “in”, that means ESP could be filtered by the upstream modem. You can try setting: set vpn ipsec site-to-site peer x.x.x.x force-encapsulation enable

This encapsulates ESP (encapsulating security payload) into UDP 4500 with NAT-T 2. If the tunnel is up, but you can’t ping, check if traffic is making it across. Source a ping from an actual client on the LAN (not the USG itself) destined for a client on the remote LAN over the VPN. If your VPN has “enable dynamic routing” configured (or is “auto”), it’s a route-based VPN provisioned with VTI. You can see this in “show ip route”

To see if traffic is traversing the tunnel run these commands on the USG while sending a ping to a remote client:

sudo tcpdump -npi vti0 (if using **Auto IPsec VPN**)  
sudo tcpdump -npi vti64 (if **manual VPN** with dynamic routing enabled)

Take a look at the packet in/packet out counters with “show vpn ipsec sa”, see if any are making it across. Packets out means the USG is sending them across the tunnel, packets in means it’s receiving them.