UniFi - Verifying and Troubleshooting IPsec VPN on USG


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 and the USG‑PRO‑4.
  • 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.

VPN Widget in the GUI


In the UniFi Controller Dashboard page, a red status bubble indicates that there is an issue with the site-to-site VPN. 

A green status bubble indicates that the VPN is functioning correctly. Hovering over this bubble gives more information on total VPN usage.


SSH Session on the USG


CLI: Access the command line interface (CLI). You can do this using the CLI button in the GUI or by using a program such as PuTTY.

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]
NoteThis 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 you can 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.


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:

  1. Configure
  2. Set vpn ipsec site-to-site peer x.x.x.x authentication id <public_ip_of_modem or upstream router>
    1. This is because the USG will advertise it’s private address as its ID, while the remote side will be expecting the public address.

Tunnel Up, No ICMP Reply:

  1. If you see the tunnel up but can’t ping across, type show vpn ipsec sa and look at the packets in/out. If you see “out” packets but no 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:

  1. sudo tcpdump -npi vti0 (if auto-vpn)
  2. sudo tcpdump -npi vti64 (if manual with dynamic routing enabled)
  3. 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.

Related Articles


Back to Top

UniFi - USG VPN: How to Configure Site-to-Site VPN


We're sorry to hear that!