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
Steps: How to Verify IPsec Tunnel Operation
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
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:
- 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 - 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.