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 Network 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 Network application 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.

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. 

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

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.

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 Network application 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.

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

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.