Overview
Readers will learn how to troubleshoot and verify IPsec Site-to-Site and Remote Access VPNs on the UDM and USG models.
- 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.
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
- Related Articles
Frequently Asked Questions (FAQ)
Do I need to manually create firewall rules for the IPsec Site-to-Site and L2TP Remote Access VPN?
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. |
What is the difference between Route-Based using Dynamic Routing and Policy-Based VPNs?
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.
|
What is SSH and what kind of program do I need to log in to the UDM/USG?
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. Enable SSH Authentication: Checked ssh <username>@<ip-address>
ssh root@192.168.1.1
ssh unifiadmin@192.168.1.1
|
Can I use a L2TP VPN if my UDM/USG is behind NAT?
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.
The Windows Firewall blocks ICMPv4 (ping) traffic by default unless a rule is added. See the Microsoft documentation here for more information.
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.
The Windows Firewall blocks ICMPv4 (ping) traffic by default unless a rule is added. See the Microsoft documentation here for more information.
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
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:
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
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 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):
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
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 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
Possible Cause #1 - The USG/UDM is located behind NAT and does not have a public IP address.
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:
|
Possible Cause #2 - The USG/UDM is forwarding either UDP port 500 or UDP port 4500 to another device.
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. |
Possible Cause #3 - The VPN client is using an incorrect pre-shared key, username, password, or authentication method.
In this situation, the L2TP VPN client and server are not using a matching pre-shared key or authentication method or credentials (username/password). 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
10[ENC] parsed INFORMATIONAL_V1 request 4065021879 [ HASH D ]
06[ENC] invalid ID_V1 payload length, decryption 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. |
Possible Cause #4 - The VPN client is trying to connect from the LAN or other non-working location.
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. |
Possible Cause #5 - There is another issue affecting the VPN client that is preventing the L2TP connection from establishing.
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
Possible Cause #1 - The VPN Client does not have the needed routes installed in the routing table.
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.
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 =========================================================================== |
Possible Cause #2 - The VPN Client is routing over the VPN, but the traffic is not allowed.
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. |
Possible Cause #3 - The VPN Client does have the needed routes and there is nothing blocking the traffic.
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
sudo tcpdump -i l2tp0 -n icmp
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 9, length 40
|
Possible Cause #4 - The VPN Client and VPN server are using the same LAN network range.
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). |
Related Articles
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