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. Steps: How to Verify IPsec Operation
2. Troubleshooting
3. Related Articles

Steps: How to Verify IPsec Tunnel Operation

Back to 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: [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: remote: [192.0.2.1] 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[1]: ESTABLISHED 5 minutes ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-1[1]: IKEv1 SPIs: 184447c009d51f80_i* 14cc0f13aff401c0_r, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-1[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[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]

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
[KNL] creating acquire job for policy 192.168.1.10/32[icmp/8] === 172.16.1.10/32[icmp/8] with reqid {1}
[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1[1] to 192.0.2.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (160 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA peer-192.0.2.1-tunnel-1[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[ENC] generating QUICK_MODE request 561157166 [ HASH SA No ID ID ]
[ENC] parsed QUICK_MODE response 561157166 [ HASH SA No ID ID N((24576)) ]
[IKE] 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: [172.20.1.242] uses pre-shared key authentication
peer-172.20.1.13-tunnel-vti: remote: [172.20.1.13] 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 [ HASH SA No KE ID ID ]
sending packet: from 172.20.1.242[500] to 172.20.1.13[500] (460 bytes)
received packet: from 172.20.1.13[500] to 172.20.1.242[500] (460 bytes)
parsed QUICK_MODE response 1747091534 [ HASH SA No KE ID ID ]
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

Back to 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. UniFi – USG Advanced Configuration

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.