Overview

Readers will learn how to troubleshoot and verify IPsec Site-to-Site and Remote Access VPNs on the UDM and USG models.

NOTES & REQUIREMENTS:

Applicable to the latest firmware on all UDM and USG models.
More information on the IPsec Site-to-Site VPNs can be found in the UDM/USG: How to Configure a Site-to-Site VPN article.
More information on the L2TP VPN server can be found in the UDM/USG: Configuring L2TP Remote Access VPN article.

Frequently Asked Questions (FAQ)
Troubleshooting Site-to-Site VPNs on the UDM
Troubleshooting Site-to-Site VPNs on the USG
Troubleshooting the L2TP Remote Access VPN
Related Articles

Frequently Asked Questions (FAQ)

Firewall rules are automatically created to allow the defined subnets (Site-to-Site) or VPN users (L2TP) to communicate over the VPN. It is not necessary to manually add firewall rules.

Route-Based VPNs (Dynamic Routing option checked) utilize VTI tunnel interfaces and static routes to send traffic over the VPN. Each VPN peer can choose which traffic to send over the VPN, for example a route to the 172.16.1.0/24 network with the next-hop set to the VTI tunnel interface.

Policy-Based VPNs (Dynamic Routing option unchecked) do not utilize any interfaces and match on specific policies to determine which traffic is sent over the VPN. A policy could be for example, a tunnel between 192.168.1.0/24 (local) and 172.16.1.0/24 (remote). Each VPN peer needs to make sure that the policies and tunnels match exactly (mirrored), otherwise the VPN will not be established or only partly connected. For example, if the UDM/USG uses the following two tunnels:

Tunnel #1 192.168.1.0/24 - 172.16.1.0/24
Tunnel #2 192.168.1.0/24 - 10.0.0.0/24

Then the remote peer needs to use:

Tunnel #1 172.16.1.0/24 - 192.168.1.0/24
Tunnel #2 10.0.0.0/24 - 192.168.1.0/24

If the remote peer uses the tunnel #2 subnets under tunnel #1 for example, then the policy does not match. Likewise, if the remote peer uses 192.168.0.0/16 instead of 192.168.1.0/24, then the policy also does not match and the VPN will not be established. Note that it is not possible to add static routes to send additional subnets over a Policy-Based VPN. Use a Route-Based VPN instead if this functionality is needed. The VPN type (Policy-Based or Route-Based) also needs to match between the peers. It is not possible to use Route-Based on one side and Policy-Based on the other.

SSH stands for Secure Shell and is a way to access the Command Line Interface (CLI) on the UDM/USG. From the command line shell you can run specific commands to display log messages that contain information on the current VPN settings.

To connect to the UDM, first enable SSH access using the steps from the How to Login to the Dream Machine using SSH article.

To connect to the USG, first enable SSH Authentication in the New Web UI Settings > Network Settings > Device Authentication section of the UniFi Controller and specify your username and password.

Enable SSH Authentication: Checked
SSH Username: <your-username>
SSH Password: <your-password>

There are many different programs that provide the SSH client functionality. On macOS and Linux computers, the Terminal can be used to open an SSH session using the ssh command. The format is:

ssh <username>@<ip-address>

To connect to the UDM that is using the default 192.168.1.1 IP address and root username, run:

ssh root@192.168.1.1

To connect to the USG that is using the default 192.168.1.1 IP address and unifiadmin username, run:

ssh unifiadmin@192.168.1.1

Windows users can either install the Windows 10 OpenSSH client or use a third-party program such as PuTTY to connect using SSH. The OpenSSH client uses the same format as the macOS/Linux command above. An example of a PuTTY session that connects to the default 192.168.1.1 IP address is:

For Site-to-Site VPNs, it is recommended to forward UDP port 500 and UDP port 4500 on the upstream router/modem to the WAN address of the UDM/USG. It is also possible to set up the VPN without port forwarding, but the UDM/USG will need to initiate the VPN and the other side should respond. This is referred to as the keyingtries value in the strongSwan documentation.

It is also necessary to configure an IPsec Authentication ID on the IPsec peer that is not behind NAT. This is referred to as the left|rightid value in the strongSwan documentation. If the UDM/USG and remote peer are both using public IP addresses to communicate (for example 203.0.113.1 and 192.0.2.1) then the Authentication IDs do not need to be manually configured because they are automatically set to the public IP addresses. If one side is behind NAT however, the Authentication ID no longer matches because the private IP address used by the UDM/USG (for example 10.0.0.1) is different from the address that is used to communicate with the peer (for example 192.0.2.1, assigned to the ISP modem/router in front of the UDM/USG). The remote peer will receive a request from 192.0.2.1 to 203.0.113.1, but the Authentication ID is set to 10.0.0.1, and will thus reject the request unless the Authentication ID is manually configured to match.

For L2TP, it is necessary to forward UDP port 500 and UDP port 4500 on the upstream router/modem to the WAN address of the UDM/USG. Using an L2TP VPN server behind NAT will cause an issue with Windows computers. These devices will no longer be able to connect as VPN connections to L2TP servers behind NAT is not allowed by default. To get around this, you will need to manually change the AssumeUDPEncapsulationContextOnSendRule registry value from 0 to 2. See the Microsoft support page here for more information.

Troubleshooting Site-to-Site VPNs on the UDM

Before following the steps below, make sure that SSH access is enabled on the UDM using the steps from the UniFi - UDM: How to Login to the Dream Machine using SSH help center article. The ping tool is vital to troubleshoot connectivity issues over the VPN. Make sure that you have access to two clients or workstations (one in each LAN) and that ping (ICMPv4) traffic is allowed through the local firewalls on the clients.

ATTENTION: Make sure that the clients are reachable via ping in their local networks before following the below steps.

The Windows Firewall blocks ICMPv4 (ping) traffic by default unless a rule is added. See the Microsoft documentation here for more information.

CLI: Access the Command Line Interface on the UDM using SSH.

1. The currently configured VPN settings can be listed with the below command:

swanctl --list-conns

Route-Based VPN (Dynamic Routing)

# swanctl --list-conns 
7c9b_4852_024a_f1e9: IKEv1, reauthentication every 28260s, dpd delay 30s
  local:  192.0.2.1
  remote: 203.0.113.1
  local pre-shared key authentication:
    id: 192.0.2.1
  remote pre-shared key authentication:
    id: 203.0.113.1
  7c9b_4852_024a_f1e9: TUNNEL, rekeying every 3060s, dpd action is restart
    local:  0.0.0.0/0
    remote: 0.0.0.0/0

Policy-Based VPN

# swanctl --list-conns 
96c4_6e7a_b0e4_4bd7: IKEv1, reauthentication every 28260s, dpd delay 30s
  local:  192.0.2.1
  remote: 203.0.113.1
  local pre-shared key authentication:
    id: 192.0.2.1
  remote pre-shared key authentication:
    id: 203.0.113.1
  96c4_6e7a_b0e4_4bd7: TUNNEL, rekeying every 3060s, dpd action is restart
    local:  172.16.1.0/24
    remote: 192.168.1.0/24

The output shows that the local and remote VPN peer IP addresses are 192.0.2.1 and 203.0.113.1 and that the VPN uses IKEv1. For Route-Based VPNs, it is normal that the local and remote subnets are displayed as 0.0.0.0/0.

2. The currently established VPNs can be listed with the below command:

swanctl --list-sas

Route-Based VPN (Dynamic Routing)

# swanctl --list-sas
7c9b_4852_024a_f1e9: #1, ESTABLISHED, IKEv1, 12cd1f31657aa086_i* 8a0c4f76b5d04a61_r
  local  '192.0.2.1' @ 192.0.2.1[500]
  remote '203.0.113.1' @ 203.0.113.1[500]
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  established 135s ago, reauth in 27711s
  7c9b_4852_024a_f1e9: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
    installed 135s ago, rekeying in 2682s, expires in 3466s
    in  cbecfd71 (0x02000000/0xfe000000),   4757 bytes,    17 packets,    26s ago
    out c44f9a74 (0x02000000/0xfe000000),   2512 bytes,    22 packets,    26s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0

Policy-Based VPN

# swanctl --list-sas
96c4_6e7a_b0e4_4bd7: #1, ESTABLISHED, IKEv1, 8961270749db1d5e_i* f715f5536c33fb30_r
  local  '192.0.2.1' @ 192.0.2.1[500]
  remote '203.0.113.1' @ 203.0.113.1[500]
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  established 72s ago, reauth in 28074s
  96c4_6e7a_b0e4_4bd7: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
    installed 72s ago, rekeying in 2532s, expires in 3529s
    in  c3c8979e,   1740 bytes,    29 packets,     1s ago
    out c73d18d6,   1740 bytes,    29 packets,     1s ago
    local  172.16.1.0/24
    remote 192.168.1.0/24

The output shows the in and out packets for each VPN tunnel. These should be roughly equal. If there are only in packets listed and no out (or vice versa), then traffic is either not entering the VPN tunnel or not arriving at the remote side. Make sure that all the VPN settings match between the peers. If there are no subnets listed at all, then the VPN is only partly established, this is likely due to mismatching VPN settings.

3. The current (live) VPN log messages can be displayed with the below command (cancel with CTRL+C):

swanctl --log

Route-Based VPN (Dynamic Routing)

# swanctl --log
06[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (180 bytes)
05[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (136 bytes)
05[ENC] parsed ID_PROT response 0 [ SA V V V ]
05[IKE] received XAuth vendor ID
05[IKE] received DPD vendor ID
05[IKE] received NAT-T (RFC 3947) vendor ID
05[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
05[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
05[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (372 bytes)
10[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (372 bytes)
10[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
10[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
10[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
05[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (76 bytes)
05[ENC] parsed ID_PROT response 0 [ ID HASH ]
05[IKE] IKE_SA 7c9b_4852_024a_f1e9[1] established between 192.0.2.1[192.0.2.1]...203.0.113.1[203.0.113.1]
05[IKE] scheduling reauthentication in 27846s
05[IKE] maximum IKE_SA lifetime 28386s
05[ENC] generating QUICK_MODE request 1975370367 [ HASH SA No KE ID ID ]
05[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (444 bytes)
11[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (444 bytes)
11[ENC] parsed QUICK_MODE response 1975370367 [ HASH SA No KE ID ID ]
11[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
11[IKE] CHILD_SA 7c9b_4852_024a_f1e9{1} established with SPIs cbecfd71_i c44f9a74_o and TS 0.0.0.0/0 === 0.0.0.0/0

Policy-Based VPN

# swanctl --log
15[IKE] sending retransmit 1 of request message ID 0, seq 1
15[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (180 bytes)
08[IKE] sending retransmit 2 of request message ID 0, seq 1
08[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (180 bytes)
13[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (136 bytes)
13[ENC] parsed ID_PROT response 0 [ SA V V V ]
13[IKE] received XAuth vendor ID
13[IKE] received DPD vendor ID
13[IKE] received NAT-T (RFC 3947) vendor ID
13[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
13[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
13[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (372 bytes)
15[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (372 bytes)
15[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
15[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
15[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
10[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (76 bytes)
10[ENC] parsed ID_PROT response 0 [ ID HASH ]
10[IKE] IKE_SA 96c4_6e7a_b0e4_4bd7[1] established between 192.0.2.1[192.0.2.1]...203.0.113.1[203.0.113.1]
10[IKE] scheduling reauthentication in 28146s
10[IKE] maximum IKE_SA lifetime 28686s
10[ENC] generating QUICK_MODE request 1662170014 [ HASH SA No KE ID ID ]
10[NET] sending packet: from 192.0.2.1[500] to 203.0.113.1[500] (444 bytes)
09[NET] received packet: from 203.0.113.1[500] to 192.0.2.1[500] (444 bytes)
09[ENC] parsed QUICK_MODE response 1662170014 [ HASH SA No KE ID ID ]
09[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
09[IKE] CHILD_SA 96c4_6e7a_b0e4_4bd7{1} established with SPIs c3c8979e_i c73d18d6_o and TS 172.16.1.0/24 === 192.168.1.0/24

The output shows a successful Route-Based and Policy-Based VPN negotiation. Note the following two lines:

Route-Based VPN (Dynamic Routing)

05[IKE] IKE_SA 7c9b_4852_024a_f1e9[1] established between 192.0.2.1[192.0.2.1]...203.0.113.1[203.0.113.1]
11[IKE] CHILD_SA 7c9b_4852_024a_f1e9{1} established with SPIs cbecfd71_i c44f9a74_o and TS 0.0.0.0/0 === 0.0.0.0/0

Policy-Based VPN

10[IKE] IKE_SA 96c4_6e7a_b0e4_4bd7[1] established between 192.0.2.1[192.0.2.1]...203.0.113.1[203.0.113.1]
09[IKE] CHILD_SA 96c4_6e7a_b0e4_4bd7{1} established with SPIs c3c8979e_i c73d18d6_o and TS 172.16.1.0/24 === 192.168.1.0/24

The first log message indicates that Phase 1 (IKE) is successfully established. This means that the pre-shared key, mode (IKEv1 / IKEv2) and the IKE encryption/hashing match between the peers. The second log message indicates that Phase 2 (ESP) is successfully established. For Route-Based VPNs, this should list 0.0.0.0/0 and for Policy-Based VPNs it should list the configured subnets.

If you are not seeing any output, then either the IPsec traffic is not arriving at the UDM or the VPN negotiation has already occurred. Use the below command to restart the IPsec process and trigger a new negotiation:

ipsec restart && sleep 1 && swanctl --log

Issue #1 - The following message is logged if the pre-shared key is incorrect:

15[ENC] invalid HASH_V1 payload length, decryption failed?
15[ENC] could not decrypt payloads
15[IKE] message parsing failed
15[IKE] ignore malformed INFORMATIONAL request

Issue #2 - The following message is logged if the IKE mode does not match (IKEv1 vs IKEv2):

08[IKE] no IKE config found for 192.0.2.1...203.0.113.1, sending NO_PROPOSAL_CHOSEN

Issue #3 - If you have configured a Route-Based VPN, but see a subnet logged, then the VPN settings do not match:

09[IKE] CHILD_SA 96c4_6e7a_b0e4_4bd7{1} established with SPIs c3c8979e_i c73d18d6_o and TS 172.16.1.0/24 === 192.168.1.0/24

4. The IPsec configuration and secrets files are located in the /run/strongswan/ipsec.d/tunnels/ directory. Use the Linux cat command to display them and replace <random-string> with the value used by your UDM:

ls -l /run/strongswan/ipsec.d/tunnels/

cat /run/strongswan/ipsec.d/tunnels/<random-string>.ipsec.s2s.config
cat /run/strongswan/ipsec.d/tunnels/<random-string>.ipsec.s2s.secret

# cat /run/strongswan/ipsec.d/tunnels/<random-string>.s2s.config 
# Generated automatically by ubios-udapi-server
# For ipsec tunnel (site-to-site) <random-string>
#
conn <random-string>

  ## basics ##
  auto=start
  authby=secret
  type=tunnel

  ## timeouts ##
  dpdaction=restart
  dpddelay=30s
  dpdtimeout=120s

  ## connection data ##
  left=192.0.2.1
  right=203.0.113.1
  mark_in=0x02000000/0xfe000000
  mark_out=0x02000000/0xfe000000

  ## routing ##
  leftsubnet=0.0.0.0/0
  rightsubnet=0.0.0.0/0
  fragmentation=yes
  compress=no

  ## phase 1 (IKE) ##
  keyexchange=ikev1
  aggressive=no
  ike=aes128-sha1-modp2048!
  reauth=yes
  ikelifetime=28800s

  ## phase 2 (ESP) ##
  esp=aes128-sha1-modp2048!
  rekey=yes
  keylife=3600s
  keyingtries=%forever
  forceencaps=no

  ## notifications ##
  leftupdown=/run/strongswan/ipsec.d/tunnels/<random-string>.ipsec.s2s.updown

# cat /run/strongswan/ipsec.d/tunnels/<random-string>.ipsec.s2s.secret 
# Generated automatically by ubios-udapi-server
# For ipsec tunnel (site-to-site) <random-string>
#
192.0.2.1 203.0.113.1 : PSK "value"

More information on these values can be found in the strongSwan documentation.

5. Hits on the automatically created IPsec firewall rules can be displayed with the commands below:

iptables -L -v -n | sed -n '/Chain UBIOS_WAN_LOCAL_USER/,$p'

ipset list UBIOS_vpn_ports

# iptables -L -v -n | sed -n '/Chain UBIOS_WAN_LOCAL_USER/,$p'
Chain UBIOS_WAN_LOCAL_USER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
 1600  384K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED /* 00000001095216663481 */
    2    80 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID /* 00000001095216663482 */
   10  2636 RETURN     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set UBIOS_vpn_ports dst /* 00000000008589937597 */
    0     0 RETURN     esp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* 00000001095216663486 */
 1489  211K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* 00000001097364144127 */

# ipset list UBIOS_vpn_ports
Name: UBIOS_vpn_ports
Type: bitmap:port
Revision: 3
Header: range 0-65535
Size in memory: 8284
References: 1
Members:
500
4500

Issue - If there are no hits (pkts), then the traffic is not arriving at the UDM. One possible reason is that the device is located behind NAT.

6. Hits on the automatically created IPsec NAT exclude rules can be displayed with the commands below:

iptables -t nat -L -v -n | sed -n '/Chain UBIOS_POSTROUTING_USER_HOOK/,$p'

ipset list UBIOS_corporate_network
ipset list UBIOS4corporate_network
ipset list UBIOS_ipsec_remote_subnets
ipset list UBIOS4ipsec_remote_subnets

# iptables -t nat -L -v -n | sed -n '/Chain UBIOS_POSTROUTING_USER_HOOK/,$p'
Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   10  4320 RETURN     all  --  *      eth8    0.0.0.0/0            0.0.0.0/0            match-set UBIOS_corporate_network src match-set UBIOS_ipsec_remote_subnets dst /* 00000001095216660481 */
  508 37915 MASQUERADE  all  --  *      eth9    0.0.0.0/0            0.0.0.0/0            /* 00000001095216660482 */
   24  1852 MASQUERADE  all  --  *      eth8    0.0.0.0/0            0.0.0.0/0            /* 00000001095216660483 */

# ipset list UBIOS_corporate_network
Name: UBIOS_corporate_network
Type: list:set
Revision: 3
Header: size 8
Size in memory: 88
References: 2
Members:
UBIOS4corporate_network
UBIOS6corporate_network

# ipset list UBIOS4corporate_network
Name: UBIOS4corporate_network
Type: hash:net
Revision: 6
Header: family inet hashsize 64 maxelem 10000
Size in memory: 1408
References: 1
Members:
172.16.1.0/24

# ipset list UBIOS_ipsec_remote_subnets
Name: UBIOS_ipsec_remote_subnets
Type: list:set
Revision: 3
Header: size 8
Size in memory: 88
References: 2
Members:
UBIOS4ipsec_remote_subnets
UBIOS6ipsec_remote_subnets

# ipset list UBIOS4ipsec_remote_subnets
Name: UBIOS4ipsec_remote_subnets
Type: hash:net
Revision: 6
Header: family inet hashsize 64 maxelem 10000
Size in memory: 1408
References: 1
Members:
192.168.1.0/24

Note that these rules are only created when using Policy-Based VPNs. It is not necessary to exclude traffic over Route-Based VPNs from NAT.

7. Traffic over the VPN can be seen by running a packet capture on the VTI (Route-Based VPNs only) and LAN interfaces.

Route-Based VPN (Dynamic Routing)

First find the VTI interface number with the below command:

ifconfig | grep vti

# ifconfig | grep vti
vti64     Link encap:UNSPEC  HWaddr C0-00-02-01-36-33-00-64-00-00-00-00-00-00-00-00

Then run a tcpdump packet capture on the tunnel interface (cancel with CTRL+C):

tcpdump -i vti64 -n icmp

# tcpdump -i vti64 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vti64, link-type RAW (Raw IP), capture size 262144 bytes
14:24:14.843981 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 55, length 40
14:24:14.845705 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 55, length 40
14:24:15.849214 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 56, length 40
14:24:15.851137 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 56, length 40
14:24:16.856831 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 57, length 40
14:24:16.858746 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 57, length 4

Use the below command to run the packet capture on the LAN interface (cancel with CTRL+C):

tcpdump -i br0 -n icmp

# tcpdump -i br0 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:24:41.948008 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 58, length 40
14:24:41.949775 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 58, length 40
14:24:42.952693 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 59, length 40
14:24:42.963633 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 59, length 40
14:24:43.959191 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 60, length 40
14:24:43.961491 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 60, length 40

Issue - If you are only seeing traffic in one direction (no replies), then it is possible that the client itself is blocking the traffic. Make sure that the clients are reachable via ping in their local networks. The Windows Firewall for example, blocks ICMPv4 (ping) traffic by default unless a rule is added. See the Microsoft documentation here for more information.

Troubleshooting Site-to-Site VPNs on the USG

Before following the steps below, make sure that SSH Authentication is enabled in the New Web UI Settings > Network Settings > Device Authentication section of the UniFi Controller and specify your username and password.

Enable SSH Authentication: Checked
SSH Username: <your-username>
SSH Password: <your-password>

The ping tool is vital to troubleshoot connectivity issues over the VPN. Make sure that you have access to two clients or workstations (one in each LAN) and that ping (ICMPv4) traffic is allowed through the local firewalls on the clients.

ATTENTION: Make sure that the clients are reachable via ping in their local networks before following the below steps.

The Windows Firewall blocks ICMPv4 (ping) traffic by default unless a rule is added. See the Microsoft documentation here for more information.

CLI: Access the Command Line Interface on the USG using SSH.

1. The currently configured VPN settings can be listed with the below commands:

sudo swanctl --list-conns

Route-Based VPN (Dynamic Routing)

unifiadmin@usg:~$ sudo swanctl --list-conns 
peer-192.0.2.1-tunnel-vti: 
  local:  203.0.113.1
  remote: 192.0.2.1
  local pre-shared key authentication:
    id: 203.0.113.1
  remote pre-shared key authentication:
    id: 192.0.2.1
  peer-192.0.2.1-tunnel-vti: TUNNEL
    local:  0.0.0.0/0
    remote: 0.0.0.0/0

Policy-Based VPN

unifiadmin@usg:~$ sudo swanctl --list-conns 
peer-192.0.2.1-tunnel-0: 
  local:  203.0.113.1
  remote: 192.0.2.1
  local pre-shared key authentication:
    id: 203.0.113.1
  remote pre-shared key authentication:
    id: 192.0.2.1
  peer-192.0.2.1-tunnel-0: TUNNEL
    local:  192.168.1.0/24
    remote: 172.16.1.0/244

2. The currently established VPNs can be listed with the below command:

sudo swanctl --list-sas
show vpn ipsec sa

Route-Based VPN (Dynamic Routing)

unifiadmin@usg:~$ show vpn ipsec sa
peer-192.0.2.1-tunnel-vti: #1, ESTABLISHED, IKEv1, 12cd1f31657aa086:8a0c4f76b5d04a61
  local  '203.0.113.1' @ 203.0.113.1
  remote '192.0.2.1' @ 192.0.2.1
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  established 161s ago, reauth in 27965s
  peer-192.0.2.1-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
    installed 160 ago, rekeying in 2446s, expires in 3441s
    in  c44f9a74,   2512 bytes,    22 packets,     3s ago
    out cbecfd71,   4757 bytes,    17 packets,    25s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0

Policy-Based VPN

unifiadmin@usg:~$ show vpn ipsec sa
peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 12cd1f31657aa086:8a0c4f76b5d04a61
  local  '203.0.113.1' @ 203.0.113.1
  remote '192.0.2.1' @ 192.0.2.1
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
  established 161s ago, reauth in 27965s
  peer-192.0.2.1-tunnel-1: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
    installed 72s ago, rekeying in 2532s, expires in 3529s
    in  c3c8979e,   1740 bytes,    29 packets,     1s ago
    out c73d18d6,   1740 bytes,    29 packets,     1s ago
    local  192.168.1.0/24
    remote 172.16.1.0/24

The output shows the in and out packets for each VPN tunnel. These should be roughly equal. If there are only in packets listed and no out (or vice versa), then traffic is either not entering the VPN tunnel on one of the peers or not arriving at the remote side. Make sure that all the VPN settings match between the peers. If there are no subnets listed at all, then the VPN is only partly established, this is likely due to mismatching VPN settings.

3. The current (live) VPN log messages can be displayed with the below command (cancel with CTRL+C):

sudo swanctl --log

Route-Based VPN (Dynamic Routing)

unifiadmin@usg:~$ sudo swanctl --log
01[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (180 bytes)
01[ENC] parsed ID_PROT request 0 [ SA V V V V V ]
01[IKE] received XAuth vendor ID
01[IKE] received DPD vendor ID
01[IKE] received FRAGMENTATION vendor ID
01[IKE] received NAT-T (RFC 3947) vendor ID
01[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
01[IKE] 192.0.2.1 is initiating a Main Mode IKE_SA
01[ENC] generating ID_PROT response 0 [ SA V V V ]
01[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (136 bytes)
07[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (372 bytes)
07[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
02[KNL] fe80::f29f:c2ff:fe05:ceb8 appeared on eth0
07[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
07[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (372 bytes)
09[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
09[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
09[CFG] looking for pre-shared key peer configs matching 203.0.113.1...192.0.2.1[192.0.2.1]
09[CFG] selected peer config "peer-192.0.2.1-tunnel-vti"
09[IKE] IKE_SA peer-192.0.2.1-tunnel-vti[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
09[IKE] scheduling reauthentication in 28126s
09[IKE] maximum IKE_SA lifetime 28666s
09[ENC] generating ID_PROT response 0 [ ID HASH ]
09[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (76 bytes)
14[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (444 bytes)
14[ENC] parsed QUICK_MODE request 1975370367 [ HASH SA No KE ID ID ]
14[ENC] generating QUICK_MODE response 1975370367 [ HASH SA No KE ID ID ]
14[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (444 bytes)
07[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (60 bytes)
07[ENC] parsed QUICK_MODE request 1975370367 [ HASH ]
07[IKE] CHILD_SA peer-192.0.2.1-tunnel-vti{1} established with SPIs c44f9a74_i cbecfd71_o and TS 0.0.0.0/0 === 0.0.0.0/0

Policy-Based VPN

unifiadmin@usg:~$ sudo swanctl --log
Starting strongSwan 5.2.2 IPsec [starter]...
16[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (180 bytes)
16[ENC] parsed ID_PROT request 0 [ SA V V V V V ]
16[IKE] received XAuth vendor ID
16[IKE] received DPD vendor ID
16[IKE] received FRAGMENTATION vendor ID
16[IKE] received NAT-T (RFC 3947) vendor ID
16[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
16[IKE] 192.0.2.1 is initiating a Main Mode IKE_SA
16[ENC] generating ID_PROT response 0 [ SA V V V ]
16[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (136 bytes)
09[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (372 bytes)
09[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
09[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
09[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (372 bytes)
15[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
15[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
15[CFG] looking for pre-shared key peer configs matching 203.0.113.1...192.0.2.1[192.0.2.1]
15[CFG] selected peer config "peer-192.0.2.1-tunnel-0"
15[IKE] IKE_SA peer-192.0.2.1-tunnel-0[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
15[IKE] scheduling reauthentication in 27867s
15[IKE] maximum IKE_SA lifetime 28407s
15[ENC] generating ID_PROT response 0 [ ID HASH ]
15[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (76 bytes)
06[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (444 bytes)
06[ENC] parsed QUICK_MODE request 1662170014 [ HASH SA No KE ID ID ]
06[ENC] generating QUICK_MODE response 1662170014 [ HASH SA No KE ID ID ]
06[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (444 bytes)
12[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (60 bytes)
12[ENC] parsed QUICK_MODE request 1662170014 [ HASH ]
12[IKE] CHILD_SA peer-192.0.2.1-tunnel-0{1} established with SPIs c73d18d6_i c3c8979e_o and TS 192.168.1.0/24 === 172.16.1.0/24

The output a successful Route-Based and Policy-Based VPN negotiation. Note the following two lines:

Route-Based VPN (Dynamic Routing)

09[IKE] IKE_SA peer-192.0.2.1-tunnel-vti[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
11[IKE] CHILD_SA peer-192.0.2.1-tunnel-vti{1} established with SPIs c75fa0be_i c2c8d324_o and TS 0.0.0.0/0 === 0.0.0.0/0

Policy-Based VPN

15[IKE] IKE_SA peer-192.0.2.1-tunnel-0[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
12[IKE] CHILD_SA peer-192.0.2.1-tunnel-0{1} established with SPIs c73d18d6_i c3c8979e_o and TS 192.168.1.0/24 === 172.16.1.0/24

If you are not seeing any output, then either the IPsec traffic is not arriving at the USG or the VPN negotiation has already occurred. Use the below command to restart the IPsec process and trigger a new negotiation:

sudo ipsec restart && sudo sleep 1 && sudo swanctl --log

Issue #1 - The following message is logged if the pre-shared key is incorrect:

15[ENC] invalid HASH_V1 payload length, decryption failed?
15[ENC] could not decrypt payloads
15[IKE] message parsing failed
15[IKE] ignore malformed INFORMATIONAL request

Issue #2 - The following message is logged if the IKE mode does not match (IKEv1 vs IKEv2):

08[IKE] no IKE config found for 192.0.2.1...203.0.113.1, sending NO_PROPOSAL_CHOSEN

Issue #3 - If you have configured a Route-Based VPN, but see a subnet logged, then the VPN settings do not match:

09[IKE] CHILD_SA 96c4_6e7a_b0e4_4bd7{1} established with SPIs c3c8979e_i c73d18d6_o and TS 172.16.1.0/24 === 192.168.1.0/24

4. The IPsec configuration and secrets files are located in the /etc/ directory. Use the Linux cat command to display them:

sudo cat /etc/ipsec.conf
sudo cat /etc/ipsec.secrets

unifiadmin@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-vti
        left=203.0.113.1
        right=192.0.2.1
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        ike=aes128-sha1-modp2048!
        keyexchange=ikev1
        ikelifetime=28800s
        esp=aes128-sha1-modp2048!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437185
        auto=route
        keyingtries=%forever
#conn peer-192.0.2.1-tunnel-vti

unifiadmin@usg:~$ sudo cat /etc/ipsec.secrets
# generated by /opt/vyatta/sbin/vpn-config.pl

203.0.113.1 192.0.2.1 : PSK "value"

More information on these values can be found in the strongSwan documentation.

5. Hits on the automatically created IPsec firewall rules can be displayed with the command below:

sudo iptables -L -v -n | sed -n '/Chain UBNT_VPN_IPSEC_FW_HOOK/,$p'

unifiadmin@usg:~$ sudo iptables -L -v -n | sed -n '/Chain UBNT_VPN_IPSEC_FW_HOOK/,$p'
Chain UBNT_VPN_IPSEC_FW_HOOK (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   22  4912 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 500,4500
  388 46560 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0

Issue - If there are no hits (pkts), then the traffic is not arriving at the USG. One possible reason for this is that the device is located behind NAT.

6. Hits on the automatically created IPsec NAT exclude rules can be displayed with the command below:

sudo iptables -t nat -L -v -n | sed -n '/Chain UBNT_VPN_IPSEC_SNAT_HOOK/,$p'

unifiadmin@usg:~$ sudo iptables -t nat -L -v -n | sed -n '/Chain UBNT_VPN_IPSEC_SNAT_HOOK/,$p'
Chain UBNT_VPN_IPSEC_SNAT_HOOK (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       192.168.1.0/24       172.16.1.0/24

Note that these rules are only created when using Policy-Based VPNs. It is not necessary to exclude traffic over Route-Based VPNs from NAT.

7. Traffic over the VPN can be seen by running a packet capture on the VTI (Route-Based VPNs only) and LAN interfaces.

Route-Based VPN (Dynamic Routing)

First find the VTI interface number and LAN interface name with the below command:

show interfaces

unifiadmin@usg:~$ show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description                 
---------    ----------                        ---  -----------                 
eth0         203.0.113.1/24                    u/u  WAN                         
eth1         192.168.1.1/24                    u/u  LAN                         
eth2         -                                 A/D                              
lo           127.0.0.1/8                       u/u                              
             ::1/128                          
vti64        -                                 u/u

Then run a tcpdump packet capture on the tunnel interface (cancel with CTRL+C):

sudo tcpdump -i vti64 -n icmp

unifiadmin@usg:~$ sudo tcpdump -i vti64 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vti64, link-type RAW (Raw IP), capture size 262144 bytes
05:22:42.703060 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 52, length 40
05:22:42.704480 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 52, length 40
05:22:43.708050 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 53, length 40
05:22:43.710065 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 53, length 40
05:22:44.720926 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 54, length 40
05:22:44.722309 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 54, length 40

Use the below command to run the packet capture on the LAN interface (cancel with CTRL+C):

NOTE: The LAN port(s) can differ depending on your setup and USG model, see the UniFi - USG/UDM-Pro: Configuring Port Remapping article for more information.

sudo tcpdump -i eth1 -n icmp

unifiadmin@usg:~$  sudo tcpdump -i eth1 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
05:25:06.271460 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 61, length 40
05:25:06.272529 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 61, length 40
05:25:07.280054 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 62, length 40
05:25:07.281039 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 62, length 40
05:25:08.285411 IP 172.16.1.10 > 192.168.1.102: ICMP echo request, id 1, seq 63, length 40
05:25:08.286728 IP 192.168.1.102 > 172.16.1.10: ICMP echo reply, id 1, seq 63, length 40

Troubleshooting the L2TP Remote Access VPN

Refer to the troubleshooting steps below if your VPN client is not able to connect to the L2TP Remote Access VPN or is not able to route traffic over the VPN. A common error message that will be logged by the VPN client is that the server is not responding, the connection failed or that there is a 'processing error'.

Unable to Connect to the L2TP VPN Server

In this scenario, the USG/UDM is located behind another router/modem that uses NAT. A sign of this setup is that the device is using a private (RFC1918) or CGNAT (RFC6598) IP address on the WAN interface. Your USG/UDM is located behind NAT if it is using an IP address on the WAN interface that is inside one of the ranges below:

10.0.0.0/8 10.0.0.0 - 10.255.255.255
172.16.0.0/12 172.16.0.0 - 172.31.255.255
192.168.x.0/24 192.168.0.0 - 192.168.255.255
100.64.0.0/10 100.64.0.0 - 100.127.255.255

To fix this issue, it is necessary to forward UDP port 500 and UDP port 4500 on the upstream router/modem to the WAN address of the USG/UDM. Using an L2TP VPN server behind NAT will also cause an issue with Windows computers. These devices will no longer be able to connect as VPN connections to L2TP servers behind NAT is not allowed by default. To get around this, you will need to manually change the AssumeUDPEncapsulationContextOnSendRule registry value from 0 to 2. See the Microsoft support page here for more information.

In this situation, the ports required for the L2TP VPN server are forwarded to a device on the LAN. To fix this issue, check if the port forwarding rules exist in the section and remove them.

It is not possible to forward UDP port 500 and UDP port 4500 to a device and use them for the L2TP VPN on the USG/UDM at the same time. Forwarded ports will take priority over the ports used by the USG/UDM itself.

In this situation, the L2TP VPN client and server are not using a matching pre-shared key or authentication method or credentials (username/password).

To fix this issue, check if the pre-shared key, username, password and authentication method (MS-CHAP v2) are configured correctly on the client using the steps above. Also check if the VPN type is set correctly to L2TP and that you are trying to authenticate with a pre-shared key and not a certificate. Retype the pre-shared key and username/password to rule out any typing errors. If the issue persists, try using a more simple pre-shared key and/or password without any characters to test the VPN.

You can determine if the settings are matching by accessing the Command Line Interface (CLI) on the USG/UDM using SSH.

NOTE: See the How to Establish a Connection Using SSH article for more information on how to connect using SSH.

1. Open a SSH session using your favorite SSH/Telnet client program (for example PuTTY or the macOS/Linux Terminal).

CLI: Access the Command Line Interface on the USG/UDM using SSH.

2. Run the command listed below. This command will print the L2TP VPN log output directly to the screen when a client tries to connect (cancel with CTRL+C).

sudo swanctl --log

3. If the output looks similar to the one below, the password, username or authentication method (MS-CHAP v2) is set incorrectly on the client.

10[ENC] parsed INFORMATIONAL_V1 request 4065021879 [ HASH D ]
10[IKE] received DELETE for ESP CHILD_SA with SPI fee7fc8c
10[IKE] closing CHILD_SA remote-access{2} with SPIs cb79748d_i (829 bytes) fee7fc8c_o (492 bytes) and TS 203.0.113.1/32[udp/l2f] === 198.51.100.1/32[udp/l2f] 
16[NET] received packet: from 198.51.100.1[500] to 203.0.113.1[500] (92 bytes)
16[ENC] parsed INFORMATIONAL_V1 request 554951473 [ HASH D ]
16[IKE] received DELETE for IKE_SA remote-access[2]
16[IKE] deleting IKE_SA remote-access[2] between 203.0.113.1[203.0.113.1]...198.51.100.1[198.51.100.1]

4. If the output looks similar to the one below, the pre-shared key is set incorrectly on the client.

06[ENC] invalid ID_V1 payload length, decryption failed?
06[ENC] could not decrypt payloads
06[IKE] message parsing failed
06[ENC] generating INFORMATIONAL_V1 request 1368947812 [ HASH N(PLD_MAL) ]
06[NET] sending packet: from 203.0.113.1[500] to 198.51.100.1[500] (76 bytes)
06[IKE] ID_PROT request with message ID 0 processing failed

5. If there is no output at all, the client is unable to reach the IP address of the USG/UDM or is using certificate authentication instead of a pre-shared key. One possible reason as to why the client is not able to reach the L2TP server, is that the UDM/USG is behind NAT. See Cause #1 above.

In this situation, the L2TP VPN client is trying to connect to the L2TP server from the LAN behind the USG/UDM or from a location that does not allow VPN connections. To fix this issue, try connecting from a different wired/wireless network or location. You can also try connecting over a mobile network, for example by creating a tethered Wi-Fi network (hotspot) on a mobile device.

To fix this issue, try using a different client or operating system. You can also check if there are any updates available for your device that may have fixes for the VPN client feature.

Unable to Route over the L2TP VPN Connection

In this situation, the VPN client is able to connect to the VPN but is not able to reach any of the hosts on the LAN network.

Windows and macOS computers both have an option to route all traffic over the VPN (default gateway). This is the default on Windows computers, but it has to be manually enabled on macOS computers using the Send all traffic through the VPN connection option in the System Preferences > Network > VPN L2TP > Advanced section.

If you are intending to use a 'split tunneling' setup and disable the gateway option on your clients, then you will need to manually add the necessary routes to the routing tables on the clients. The L2TP VPN is unable to push any routes to the client devices.

If you are intending to use a 'split tunneling' setup and disable the gateway option on your clients, then you will need to manually add the necessary routes to the routing tables on the clients. The L2TP VPN is unable to push any routes to the client devices.

A workaround when using 'split tunneling' (default gateway is not set) is the generation of a single classful route on the client that is automatically installed in the routing table. This route will depend on the Gateway IP / Subnet that you specify for the L2TP VPN in the UniFi controller settings. The following classful routes will be added based on the subnet used for the L2TP VPN:

10.0.0.0/8 L2TP VPN subnet is configured with a 10.x.x.x address, for example 10.10.1.1/24.
172.16.0.0/12 L2TP VPN subnet is configured with a 172.16-31.x.x address, for example 172.16.1.1/24.
192.168.x.0/24 L2TP VPN subnet is configured with a 192.168.x.x address, for example 192.168.2.1/24.

You can use this functionality to your advantage. For example, you are using the 10.0.10.0/24 IP address range for your LAN and want remote L2TP VPN clients to be able to connect to your LAN, but not route all traffic over the VPN (split tunneling). If you configure the Gateway IP / Subnet in the 10.x.x.x range, for example 10.255.20.1/24, the VPN clients will install a 10.0.0.0/8 route in their routing tables and can communicate with the 10.0.10.0/24 network over the VPN.

Below is an example of a Windows computer that is connected to a L2TP server that uses 10.255.20.1/24 as the Gateway IP / Subnet. Note that a 10.255.20.1/32 route (255.255.255.255) and a 10.0.0.0/8 route (255.0.0.0) are installed in the routing table.

C:\WINDOWS\system32>route print -4
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.1.1     172.16.1.100    281
>        10.0.0.0        255.0.0.0     10.255.255.0      10.255.20.1     26
>     10.255.20.1  255.255.255.255         On-link       10.255.20.1    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
       172.16.1.0    255.255.255.0         On-link      172.16.1.100    281
       172.16.1.1  255.255.255.255         On-link      172.16.1.100     26
     172.16.1.100  255.255.255.255         On-link      172.16.1.100    281
     172.16.1.255  255.255.255.255         On-link      172.16.1.100    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      172.16.1.100    281
        224.0.0.0        240.0.0.0         On-link       10.255.20.1    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      172.16.1.100    281
  255.255.255.255  255.255.255.255         On-link       10.255.20.1    281
===========================================================================

In this situation, the VPN client is able to connect to the VPN but is not able to reach any of the hosts on the LAN network.

Verify if there are any LAN_IN or LAN_OUT firewall rules configured that might prevent the remote VPN clients from communicating with the LAN. Also verify that the default gateway is set correctly on the LAN devices and that they are able to respond to the traffic. You can verify the LAN firewall configuration in the Settings > Internet Security > Firewall > LAN section.

Another reason why the connection might fail is that the LAN clients are actively dropping the traffic at their local firewalls. The Windows Firewall for example, drops all ICMPv4 (ping) traffic by default. If you are testing with ping, then you will need to allow this traffic through the Windows firewall. See the Microsoft support page here for more information.

You can determine if there is actually traffic going over the VPN by accessing the Command Line Interface (CLI) on the USG/UDM using SSH and running a tcpdump packet capture.

NOTE: See the How to Establish a Connection Using SSH article for more information on how to connect using SSH.

1. Open a SSH session using your favorite SSH/Telnet client program (for example PuTTY or the macOS/Linux Terminal).

CLI: Access the Command Line Interface on the USG/UDM using SSH.

2. The command listed below will print all traffic that is going over the L2TP VPN directly to the screen (cancel with CTRL+C).

sudo tcpdump -i l2tp0 -n

3. You can optionally limit the packet capture to just ICMPv4 (ping) traffic with the command below.

sudo tcpdump -i l2tp0 -n icmp

4. If the output looks similar to the one below, the LAN host (192.168.1.100 in this example) is not responding to the requests from the L2TP client (192.168.2.1). See Cause #2 above.

IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 5, length 40
IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 6, length 40
IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 7, length 40
IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 8, length 40

5. If the output looks similar to the one below, the LAN host (192.168.1.100 in this example) and the L2TP client (192.168.2.1) are able to communicate with ping. If an additional protocol such as RDP or HTTPS is not working over the VPN, then the traffic may still be blocked by a LAN_IN or LAN_OUT firewall rule or by the firewall on the LAN device itself. See Cause #2 above.

IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 9, length 40
IP 192.168.1.100 > 192.168.2.1: ICMP echo reply, id 1, seq 9, length 40
IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 10, length 40
IP 192.168.1.100 > 192.168.2.1: ICMP echo reply, id 1, seq 10, length 40
IP 192.168.2.1 > 192.168.1.100: ICMP echo request, id 1, seq 11, length 40
IP 192.168.1.100 > 192.168.2.1: ICMP echo reply, id 1, seq 11, length 40

6. If there is no output, the L2TP client is either not connected to the VPN or does not have the needed routes. See Cause #1 above.

7. If you are using a hostname instead of an IP address to connect, then it is also possible that the hostname is not successfully resolving. To verify this, test the connection using an IP address instead.

In this situation, the VPN client is able to connect to the VPN but is not able to reach any of the hosts on the LAN network. This is caused by the fact that the LAN network used by the client and the UniFi LAN are the same (192.168.1.0/24 for example).

The VPN client will always prefer the locally connected network over the network that is accessible over the VPN. One way to fix this issue is by changing the UniFi LAN network range or the local network used by the client. You can change the UniFi LAN network range in the Settings > Networks > Local Networks > LAN > Edit section.

A workaround for this issue is to manually add routes to the client that are more specific than the locally connected network. For example, if the client and UniFi LAN network are both using the 192.168.1.0/24 range, the client will not route any traffic for 192.168.1.0/24 over the VPN. However, if you add more specific routes to the client, for example 192.168.1.0/25 and 192.168.1.128/25, the client will start using the VPN.

Using NAT on the USG/UDM to translate the ranges is not a workaround in this case, because the client is not even routing the traffic over the VPN. If the client is not sending any traffic to the server, the server (USG/UDM) cannot influence the traffic in any way.

You can determine if there is actually traffic going over the VPN by accessing the Command Line Interface (CLI) on the USG/UDM using SSH and running a tcpdump packet capture. See Cause #3 above.

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

UniFi - USG/UDM: Configuring L2TP Remote Access VPN

Intro to Networking - How to Establish a Connection Using SSH

UniFi - UDM: How to Login to the Dream Machine using SSH

UniFi - UDM/USG: Verifying and Troubleshooting IPsec VPNs

Overview

Table of Contents

Frequently Asked Questions (FAQ)

Troubleshooting Site-to-Site VPNs on the UDM

Troubleshooting Site-to-Site VPNs on the USG

Troubleshooting the L2TP Remote Access VPN

Unable to Connect to the L2TP VPN Server

Unable to Route over the L2TP VPN Connection

Related Articles