Overview

Readers will learn how to set up an L2TP VPN server on the USG and UDM models using RADIUS authentication.

NOTES & REQUIREMENTS:

Applicable to the latest firmware on all USG and UDM models.
The L2TP VPN is designed to only work on WAN1 on the USG models, but it can use both WAN1 and WAN2 on the UDM-Pro.
More information on the USG/UDM RADIUS server can be found in the Configuring RADIUS Server article.
Join the UniFi discussion on the Ubiquiti Community and interact with other experts that are active on forum.

Frequently Asked Questions (FAQ)
Configuring the L2TP Server
Setting up the L2TP Client
Troubleshooting L2TP Connection or Routing Issues
Related Articles

Frequently Asked Questions (FAQ)

Firewall rules are automatically created to allow the VPN users to connect (authenticate) and route traffic over the VPN. It is not necessary to manually add firewall rules for L2TP.

RADIUS is a protocol that is used to authenticate and authorize users. Username and passwords are stored in a database and this database is consulted when a remote VPN client tries to connect. If the credentials provided by the remote VPN client match the ones in the database, the client is allowed to connect.

The RADIUS Profile determines which device (server) is used to authenticate the users. The Default profile uses the USG/UDM itself as the server. By default, the RADIUS server is not enabled and no users are created.

You can enable the RADIUS server and add RADIUS users in the Settings > Gateway > Radius section of the New Web UI. When using the Classic Web UI, navigate to the Settings > Services > Radius section instead.

On the latest UniFi Controller firmware releases, you can configure both L2TP and UPnP on the same device and they will not interfere with each other.

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.

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
===========================================================================

Yes, but 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 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.

Configuring the L2TP Server

The diagram below shows an example setup where the ISP provided modem/router is running in a bridged mode and the UDM-Pro is using a public IP address on the WAN interface.

After connecting to the L2TP VPN server running on the USG/UDM and authenticating to the built-in RADIUS server, the remote VPN clients will be allowed to communicate with the devices on the LAN.

GUI: Access the UniFi Controller Web Portal.

Follow the steps below to configure the L2TP VPN server and RADIUS server on the USG/UDM models:

Use this option if you quickly want to set up a Basic L2TP VPN server. Use the Advanced setup instead if you want to customize the settings.

1. Navigate to the Settings > VPN > VPN Servers > Create New VPN Server > Create section to add the L2TP server.

2. Select Create Basic VPN and enter the following settings:

Step 1 of 3 - Basic VPN

Enter VPN Name: l2tp
Gateway IP / Subnet: 192.168.2.1/24

Step 2 of 3 - RADIUS

Enable RADIUS Server: Checked
Pre-Shared Key: <shared-secret>

NOTE: The pre-shared key is a common password used to authenticate all VPN users to the L2TP Server.

Step 3 of 3 - Add Users

Enter User Name: user1
Enter Password: <user1-password>
Enter VLAN ID: None

NOTE: The username and password configured here are unique for each individual VPN user.

3. Apply the changes. The L2TP VPN is now successfully configured.

4. If needed, additional VPN users can be added in the Settings > Gateway > Radius section. Each user needs to use a unique name.

5. The next step is to add the VPN client configuration to your computer(s). See the section below if you are experiencing issues connecting to the VPN after completing the VPN client configuration steps.

1. Navigate to the Settings > Gateway > Radius section to enable the RADIUS server.

2. Enable the RADIUS server and specify the RADIUS Secret.

NOTE: The RADIUS secret is used to authenticate the RADIUS server to the RADIUS client. In this case, both the client and server are the same device, the USG/UDM. This secret does not have to match the pre-shared key used for the L2TP VPN.

3. Apply the changes.

4. Add a new RADIUS user with the Create New User option.

Enter User Name: user1
Enter Password: <user1-password>
Enter VLAN ID: None
Tunnel Type: 3 - Layer Two Tunneling Protocol (L2TP)
Tunnel Medium Type: 1 - IPv4 (IP version 4)

NOTE: The username and password configured here are unique for each individual VPN user.

5. Apply the changes.

6. Add more RADIUS users if necessary. Each user needs to use a unique name.

7. Navigate to the Settings > VPN > VPN Servers > Create New VPN Server > Create section to add the L2TP server.

8. Select Create Advanced VPN and enter the following settings:

Step 1 of 3 - VPN Server

Enter VPN Name: l2tp
Enable: Checked
VPN Type: L2TP Server
Pre-Shared Key: <shared-secret>
Gateway IP / Subnet: 192.168.2.1/24

NOTE: The pre-shared key is a common password used to authenticate all VPN users to the L2TP Server.

Step 2 of 3 - DHCP

Name Server: Auto
WINS Server: Unchecked
Site-to-Site VPN: Unchecked

Step 3 of 3 - RADIUS

Radius Profile: Default
MS-CHAP v2: Unchecked

9. Apply the changes. The L2TP VPN is now successfully configured.

10. The next step is to add the VPN client configuration to your computer(s). See the section below if you are experiencing issues connecting to the VPN after completing the VPN client configuration steps.

1. Navigate to the Settings > Services > Radius section to enable the RADIUS server.

2. Enable the RADIUS server from the Server tab and specify the RADIUS Secret.

3. Apply the changes.

4. Add a new RADIUS user from the Users tab.

Name: user1
Password: <user1-password>
VLAN: None
Tunnel Type: 3 - Layer Two Tunneling Protocol (L2TP)
Tunnel Medium Type: 1 - IPv4 (IP version 4)

NOTE: The username and password configured here are unique for each individual VPN user.

5. Apply the changes.

6. Add more RADIUS users if necessary. Each user needs to use a unique name.

7. Navigate to the Settings > Networks > Create New Network section to add the L2TP server.

8. Select Remote User VPN and add the following information:

Name: l2tp
Purpose: Remote User VPN
VPN Type: L2TP Server
Pre-Shared Key: <shared-secret>
Gateway IP/Subnet: 192.168.2.1/24
Name Server: Auto
WINS Server: Unchecked
Site-to-Site VPN: Unchecked
RADIUS Profile: Default
MS-CHAP v2: Unchecked

NOTE: The pre-shared key is a common password used to authenticate all VPN users to the L2TP Server

9. Save the changes.

Setting up the L2TP Client

After configuring the L2TP VPN server in the section above, add the L2TP VPN client configuration to your computer. Follow the steps below depending on your operating system:

1. Add a new VPN connection in the Network & Internet settings.

Settings > Network & Internet > VPN > Add a VPN connection

VPN Provider: Windows (built-in)
Connection name: l2tp
Server name: <ip address or hostname of usg/udm>
VPN Type: L2TP/IPsec with pre-shared key
Pre-shared key: <shared-secret>
Type of sign-in info: User name and password
User name: user1
Password: <user1-password>

2. Navigate to the Windows 10 network connections to change the allowed security protocols.

Settings > Network & Internet > Status > Change Adapter Options > L2TP Adapter properties

3. Select the Security tab and set the authentication method to MS-CHAP v2.

Security > Allow these protocols > Microsoft CHAP Version 2 (MS-CHAP v2)

4. After connecting to the VPN, you can verify the routing table from a Command Shell (CMD) or PowerShell window by running the following command:

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   4506
>         0.0.0.0          0.0.0.0         On-link       192.168.2.1     26
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4556
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4556
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
      192.168.2.1  255.255.255.255         On-link       192.168.2.1    281
       172.16.1.0    255.255.255.0         On-link      172.16.1.100   4506
       172.16.1.1  255.255.255.255         On-link      172.16.1.100   4251
     172.16.1.100  255.255.255.255         On-link      172.16.1.100   4506
     172.16.1.255  255.255.255.255         On-link      172.16.1.100   4506
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4556
        224.0.0.0        240.0.0.0         On-link      172.16.1.100   4506
        224.0.0.0        240.0.0.0         On-link       192.168.2.1     26
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
  255.255.255.255  255.255.255.255         On-link      172.16.1.100   4506
  255.255.255.255  255.255.255.255         On-link       192.168.2.1    281
===========================================================================

5. Note that reachability to the UniFi LAN network is accomplished by the installation of a secondary default route. This is the default behavior on Windows computers.

6. If you want to use 'split tunneling' instead of routing all traffic over the VPN, see the FAQ above. The installation of the default gateway can be controlled by checking or unchecking the Use default gateway on remote network option in the Networking > Internet Protocol Version 4 (TCP/IPv4) > Properties > Advanced section. Afterwards, verify the routing table on the client again and add the needed routes.

1. Add a VPN connection in the Network settings.

System Preferences > Network > "+"

Interface: VPN
VPN Type: L2TP over IPSec
Service name: l2tp

2. Adjust the settings of the newly created L2TP over IPsec interface.

System Preferences > Network > L2TP over IPsec Interface

Configuration: Default
Server Address: <ip address or hostname of usg/udm>
Account Name: user1

3. Select Authentication Settings... to add the pre-shared secret and the user password.

User Authentication > Password: <user1-password>
Machine Authentication > Shared Secret: <shared-secret>

4. Select Advanced... to add send all traffic through the VPN connection.

Options > Session Options: Send all traffic over VPN connection (checked)

5. After connecting to the VPN, you can verify the routing table from a Terminal window by running the following command:

:~ root$ netstat -nr -f inet
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
> default          link#7             UCS            28        0    ppp0       
default            172.16.1.1         UGScI           4        0     en0       
10.255.255.0       192.168.2.1        UH              0        0    ppp0       
127                127.0.0.1          UCS             0        0     lo0       
127.0.0.1          127.0.0.1          UH              1      130     lo0       
169.254            link#5             UCS             0        0     en0      !
192.168.1.1        link#7             UHWIi           8      265    ppp0       
192.168.2          ppp0               USc             1        0    ppp0       
172.16.1           link#5             UCS             1        0     en0      !
172.16.1.1         ab:cd:ab:cd:ab:cd  UHLWIir         5      484     en0   1199
172.16.1.100/32    link#5             UCS             0        0     en0      !
224.0.0/4          link#7             UmCS            2        0    ppp0       
224.0.0/4          link#5             UmCSI           0        0     en0      !
224.0.0.251        link#7             UHmW3I          0        0    ppp0   3576
239.255.255.250    link#7             UHmW3I          0        8    ppp0   2511
255.255.255.255/32 link#7             UCS             0        0    ppp0       
255.255.255.255/32 link#5             UCSI            0        0     en0      !

6. Note that reachability to the UniFi LAN network is accomplished by the installation of a secondary default route. This is the result of checking the Send all traffic over VPN connection option in step 4 above.

7. Uncheck this option if you want to use 'split tunneling' instead of routing all traffic over the VPN, see the FAQ above. Afterwards, verify the routing table on the client again and add the needed routes.

Troubleshooting L2TP Connection or Routing Issues

Refer to the troubleshooting steps below if the VPN client is not able to connect to the 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.

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 > 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: Configuring RADIUS Server

Intro to Networking - Virtual Private Networks & Tunneling

Intro to Networking - How to Establish a Connection Using SSH

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

UniFi - Verifying and Troubleshooting IPsec VPN on USG

UniFi - USG/UDM: Configuring L2TP Remote Access VPN

Overview

Table of Contents

Frequently Asked Questions (FAQ)

Configuring the L2TP Server

Setting up the L2TP Client

Troubleshooting L2TP Connection or Routing Issues

Unable to Connect to the L2TP VPN Server

Unable to Route over the L2TP VPN Connection

Related Articles