EdgeRouter - L2TP IPsec VPN Server using RADIUS

Overview


Readers will learn how to configure the EdgeRouter as a L2TP (Layer 2 Tunneling Protocol) server using RADIUS authentication. Please see the L2TP IPsec VPN Server for information on how to setup local authentication with L2TP. This example is based on 'pre-shared-secret' authentication and does not focus on 'certificate-based' authentication. 

 book_25x25.png  Notes & Requirements:

Applicable to EdgeOS 1.9.1+ firmware in all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and basic networking knowledge is required. Find a basic article on the subject in the Related Articles below and see the attachments for the configuration used in this article.

 

Equipment used in this article:

EdgeRouter-X (ER-X)

- Test clients behind the peers (Host1 and Server1)

- Windows Server 2016 Network Policy Server (NPS)

Table of Contents


  1. Network Diagram
  2. Steps - L2TP Server 
  3. Steps - Firewall Rules 
  4. Steps - Windows Client
  5. Steps - Testing and Verification
  6. Related Articles

Network Diagram


Back to Top

The network topology is shown below. The IP addresses and interfaces used by Host1 and the client router are not relevant in this example. Using the L2TP terminology, the ER-X is the 'L2TP server', whereas Host1 is the 'L2TP client'.

The following interfaces are in use on the ER:

  1. eth0 (WAN) - 203.0.113.1
  2. eth1 (LAN) - 192.168.1.1/24

 


Steps - L2TP Server


Back to Top

In this example the ER has been pre-configured using the Basic Setup wizard. For the purpose of this article we will assume that the masquerade rules are in place so that the hosts on the LAN can communicate with hosts on Internet.

The UDP ports and protocols relevant to L2TP are:

  1. UDP 1701 (L2TP)
  2. UDP 500 (IKE)
  3. ESP (Protocol 50)
  4. UDP 4500 (NAT-T) 

 

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

1. Enter configuration mode.

configure

2. Configure the server authentication settings (replace <secret> with your desired passphrase).

set vpn l2tp remote-access ipsec-settings authentication mode pre-shared-secret
set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret <secret>
info_i_25x25.png Note: If you define a pre-shared-secret using 'quotation marks', make sure that the secret on the client side does not include these same quotes. For example set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret 'sup3rSecure' must be entered as sup3rSecure on the client. 

3. Create the IP address information to be used by the VPN clients.

set vpn l2tp remote-access client-ip-pool start 192.168.100.240
set vpn l2tp remote-access client-ip-pool stop 192.168.100.249
info_i_25x25.png Note: You can also issue IP addresses the local subnet (192.168.1.0/24 in this case), but make sure that they do not overlap with IP addresses issued by your DHCP Server or used by other devices on your network. Defining addresses in the same range as the local subnet is not recommended because it can lead to issues with applications that rely on multicast (discovery).

4. Define the DNS server(s) that will be used by the VPN clients.

set vpn l2tp remote-access dns-servers server-1 8.8.8.8
set vpn l2tp remote-access dns-servers server-2 8.8.4.4

You can also set the DNS server to be the internal IP of the router itself. In this case you will also need to enable DNS forwarding (if not already enabled) and set listen-address to the same internal IP.

set vpn l2tp remote-access dns-servers server-1 192.168.1.1
set service dns forwarding options "listen-address=192.168.1.1"
set service dns forwarding cache-size 150
set service dns forwarding listen-on eth1

5. Define the WAN interface which will receive L2TP requests from clients.

Configure only one of the following statements. Decide on which command is best for your situation using these options:

(A) Your WAN interface receives an address through DHCP.

set vpn l2tp remote-access dhcp-interface eth0

(B) Your WAN interface is configured with a static address (replace value with your external address).

set vpn l2tp remote-access outside-address 203.0.113.1

(C) Your WAN interface receives an address through PPPoE, or you are using Dual WAN Load-Balancing.

set vpn l2tp remote-access outside-address 0.0.0.0
info_i_25x25.png Note: Use option C when multiple uplinks are used (Dual WAN Load-balancing). If you use either option A or B your L2TP server will only be reachable on a single WAN address.

6. Configure the RADIUS authentication (replace <secret> with your desired passphrase).

set vpn l2tp remote-access authentication mode radius
set vpn l2tp remote-access authentication radius-server 192.168.1.10 key <secret>

7. (Optional) Define the IPsec interfaces to be used for L2TP.

This step depends on the firmware version that is being used. Officially the usage of this command has been deprecated in v1.8.5. More information under the 'Enhancements and bug fixes' section in the EdgeMAX EdgeRouter software release v1.8.5.

set vpn ipsec ipsec-interfaces interface eth0

8. (Optional) Lower the MTU for L2TP traffic.

Experiment with lowering the MTU value if the performance of the L2TP tunnel is poor. Example use cases when this can happen is when the external WAN interface uses PPPoE (1492 byte MTU).

set vpn l2tp remote-access mtu <mtu-value>

9. (Optional) Require the VPN clients to use a specific authentication protocol when connecting.

set vpn l2tp remote-access authentication require [ pap | chap | mschap | mschap-v2 ]
  • PAP - Require Password Authentication Protocol 
  • CHAP - Require Challenge Handshake Authentication Protocol 
  • MS-CHAP - Require Microsoft Challenge Handshake Authentication Protocol
  • MS-CHAP-V2 - Require Microsoft Challenge Handshake Authentication Protocol Version 2

10. Commit the changes.

commit

11. Save the configuration.

save

Steps - Firewall Rules


Back to Top

The WAN_LOCAL rule created by the Basic Setup wizard does not allow any incoming connections by default. Firewall rules for L2TP, ESP and IKE need to be created in order to accept the VPN traffic.

1. Enter configuration mode.

configure

2. Add additional firewall rules for L2TP, IKE, NAT-T and ESP for the WAN interface(s).

warning_25x25.png Attention: Make sure that these firewall rules do not override your existing rules. Verify which rules are in place with the show firewall name WAN_LOCAL configuration mode statement, or by looking in the GUI under Firewall / NAT > Firewall Policies > WAN_LOCAL > Actions > Edit Ruleset.
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 description IKE
set firewall name WAN_LOCAL rule 30 destination port 500
set firewall name WAN_LOCAL rule 30 log disable
set firewall name WAN_LOCAL rule 30 protocol udp

set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 description L2TP
set firewall name WAN_LOCAL rule 40 destination port 1701
set firewall name WAN_LOCAL rule 40 log disable
set firewall name WAN_LOCAL rule 40 protocol udp

set firewall name WAN_LOCAL rule 50 action accept
set firewall name WAN_LOCAL rule 50 description ESP
set firewall name WAN_LOCAL rule 50 log disable
set firewall name WAN_LOCAL rule 50 protocol esp

set firewall name WAN_LOCAL rule 60 action accept
set firewall name WAN_LOCAL rule 60 description NAT-T
set firewall name WAN_LOCAL rule 60 destination port 4500
set firewall name WAN_LOCAL rule 60 log disable
set firewall name WAN_LOCAL rule 60 protocol udp
info_i_25x25.png Note: The name of the local firewall rule applied to the WAN interface might be different in your environment. Whatever the naming scheme, make sure that the correct firewall rule is applied under the WAN interface, or manually apply it with the set interfaces ethernet eth0 firewall local name <firewall name> statement.

3. Commit the changes.

commit 

4. Save the configuration.

save

Steps - RADIUS Server


Back to Top

The section below (briefly) focuses on configuring the Network Policy and Access Services (NPS) role on a Windows 2016 server. There are multiple guides available online that go into more detail than this article.

1. Add the NPS role.

Server Manager > Add Roles and Features > Network Policy and Access Services

2. Add the EdgeRouter to the RADIUS clients (replace <secret> with your desired passphrase).

Network Policy Server Console (NPS) > Radius Clients and Servers > Radius Clients > New

Friendly Name: ER-X (does not have to match device hostname)
Address (IP or DNS): 192.168.1.1 (the source address of the router)
Shared Secrets Template: None
Shared Secret: Manual
Shared Secret / Confirm: <secret>
info_i_25x25.png Note: You can also create a ‘RADIUS Shared Secret Template’ and use the same passphrase for all RADIUS Clients.

3. Create a Network Policy for the RADIUS clients.

NPS > Policies > Network Policy > New

Policy Name: ER Radius Clients
Type of Network Access Server: Unspecified

Specify Conditions > Add

Client Friendly Name: ER-?
User Groups: UBNT\Network Engineers
info_i_25x25.png Note: You can use Active Directory (AD) or local users (Windows Group) for authentication. In this example the users allowed to authenticate to the ER are ‘Network Engineers’ in the UBNT domain. You can use expressions when matching the ‘Client Friendly Name’. For example 'ER-?' matches device names starting with 'ER-'.

Next > Specify Access Permission

Access Granted

Next > Configure Authentication Methods

Uncheck all methods and check ‘Microsoft Encrypted Authentication Version 2 (MS-CHAP-v2)’

Next > Configure Constraints > Next > Configure Settings > Radius Attributes: Standard

Framed-Protocol: PPP
Service-Type: Framed


Steps - Windows Client


Back to Top

There are different ways to connect to an L2TP server using a multitude of applications and operating systems. In this article we are focusing on just one, the built-in Windows 10 VPN client. The reason for choosing this method is that it is commonly used and it also has a major caveat that is worth discussing.

1. Navigate to the Windows 10 Settings (WIN+I) > Network & Internet > Add a VPN connection

  1. VPN Provider: Windows (built-in)
  2. Connection name: ER-L2TP
  3. Server name: Your ER external WAN IP-address
  4. VPN Type: L2TP/IPsec with pre-shared key or certificate

2. Navigate to the Windows 10 Network Connections (WIN+X) > ER-L2TP Adapter properties

Security > Allow these protocols > Microsoft CHAP Version 2 (MS-CHAP v2)
info_i_25x25.png Note: If your EdgeRouter is sitting behind NAT and you cannot connect to your L2TP server, it might be due to the Windows operating system and the way it handles IPsec traffic to servers/routers that are located behind a NAT device. In this case apply the hotfix in step 3.

3. power_bolt_25x25.png(Hotfix) Navigate to the Windows 10 registry (WIN+R) > regedit

Locate the following registry subtree:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent

Create a new DWORD (32-bit) value in this subtree:

AssumeUDPEncapsulationContextOnSendRule

Modify the newly created DWORD value and give it a value of 2 (default is 0) and restart your computer.


Steps - Testing & Verification


Back to Top

The last step is to test and verify the arrival of the L2TP traffic on the external interface and verify the logs. If there is any issue with the L2TP VPN, please verify the log files to identify the problem. After initiating the L2TP session verify the connection using the following commands and output on the RADIUS Server:

1. The incoming and outgoing requests on the defined UDP port (1812):

sudo tcpdump -i eth1 -n -vv udp dst port 1812
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:15:08.874836 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 161)
192.168.1.1.37642 > 192.168.1.10.1812: [udp sum ok] RADIUS, length: 133
Access-Request (1), id: 0x91, Authenticator: 522ab5d069e26abc7782f7433119a087
Service-Type Attribute (6), length: 6, Value: Framed
0x0000: 0000 0002
Framed-Protocol Attribute (7), length: 6, Value: PPP
0x0000: 0000 0001
User-Name Attribute (1), length: 7, Value: user1
0x0000: 7573 6572 31
Vendor-Specific Attribute (26), length: 24, Value: Vendor: Microsoft (311)
Vendor Attribute: 11, Length: 16, Value: X.wN......aDn4.o
0x0000: 0000 0137 0b12 58eb 774e 0690 81c9 b38a
0x0010: 6144 6e34 e66f
Vendor-Specific Attribute (26), length: 58, Value: Vendor: Microsoft (311)
Vendor Attribute: 25, Length: 50, Value: ...TT........_..............A..+..4Y.....X.u.._...
0x0000: 0000 0137 1934 f300 0954 54e8 87a6 8cc1
0x0010: cbeb 865f 1006 00f2 0000 0000 0000 0000
0x0020: a7c2 41f4 cb2b 921a 3459 9eed 8792 d358
0x0030: 8d75 b188 5f99 1aa7
NAS-IP-Address Attribute (4), length: 6, Value: 127.0.1.1
0x0000: 7f00 0101
NAS-Port Attribute (5), length: 6, Value: 0
0x0000: 0000 0000

2. The event logs on the Radius server:

Event Viewer > Custom Views > ServerRoles > Network Policy and Access Services

3. Create a temporarily log file to view all pppd related logs:

set system syslog file radiustemporary facility all level debug
commit

run show log file radiustemporary
Jul 14 17:25:09 ubnt xl2tpd[2532]: Connection established to 192.0.2.1, 1701. Local: 26356, Remote: 19 (ref=0/0)
Jul 14 17:25:09 ubnt xl2tpd[2532]: Call established with 192.0.2.1, Local: 35889, Remote: 1, Serial: 0
Jul 14 17:25:09 ubnt pppd[7138]: Using interface ppp0
Jul 14 17:25:09 ubnt pppd[7138]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap MS-v2> <magic 0x5c8d6fbe>]
Jul 14 17:25:09 ubnt pppd[7138]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <auth chap MS-v2> <magic 0x5c8d6fbe>]
Jul 14 17:25:11 ubnt pppd[7138]: lcp_reqci: returning CONFACK.
Jul 14 17:25:11 ubnt pppd[7138]: sent [CHAP Challenge id=0x8a <5820432807b27bbc5a6be3870cad28f8>, name = "xl2tpd"]
Jul 14 17:25:11 ubnt pppd[7138]: rcvd [CHAP Response id=0x8a <d0f635e2ded9bc5058731d63455fa2a00>, name = "user1"]
Jul 14 17:25:11 ubnt pppd[7138]: sent [CHAP Success id=0x8a "S=2C2B5E6678413055975930084A5B27D78DEA339D"]
Jul 14 17:25:11 ubnt pppd[7138]: sent [IPCP ConfNak id=0x9 <addr 192.168.100.240>]
Jul 14 17:25:11 ubnt pppd[7138]: rcvd [IPCP ConfReq id=0xa <addr 192.168.100.240>]
Jul 14 17:25:11 ubnt pppd[7138]: ipcp: returning Configure-ACK
Jul 14 17:25:11 ubnt pppd[7138]: ipcp: up

delete system syslog file radiustemporary
commit

4. Verify the state of the IPsec process on the ER:

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
uptime: 49 seconds, since Jul 17 14:01:59 2017
malloc: sbrk 376832, mmap 0, used 272072, free 104760
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
Listening IP addresses:
192.168.1.1
203.0.113.1
10.255.255.0
Connections:
remote-access: 203.0.113.1...%any IKEv1, dpddelay=15s
remote-access: local: [203.0.113.1] uses pre-shared key authentication
remote-access: remote: uses pre-shared key authentication
remote-access: child: dynamic[udp/l2f] === dynamic[udp] TRANSPORT, dpdaction=clear
Security Associations (1 up, 0 connecting):
remote-access[1]: ESTABLISHED 30 seconds ago, 203.0.113.1[203.0.113.1]...192.0.2.1[172.16.1.10]
remote-access[1]: IKEv1 SPIs: 7ef8fd033bea7f4c_i 27eaafddd951c8dc_r*, rekeying disabled
remote-access[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384
remote-access{1}: INSTALLED, TRANSPORT, ESP in UDP SPIs: c009fce1_i cd73f1b4_o
remote-access{1}: AES_CBC_128/HMAC_SHA1_96, 3594 bytes_i (36 pkts, 18s ago), 675 bytes_o (17 pkts, 27s ago)
remote-access{1}: 203.0.113.1/32[udp/l2f] === 192.0.2.1/32[udp/l2f]
info_i_25x25.png Note: If the connection is not establishing, please try restarting the IPsec process using the sudo ipsec restart command.

5. Verify that the traffic is increasing the counters on the corresponding firewall rules.

show firewall name WAN_LOCAL statistics 
------------------------------------------
IPv4 Firewall "WAN_LOCAL" [WAN to router]
 Active on (eth0,LOCAL)

rule packets bytes action description
---- ------- ----- ------ -----------
10 2926 271414 ACCEPT Allow established/related
20 0 0 DROP Drop invalid state
30 19 5512 ACCEPT IKE
40 5 655 ACCEPT L2TP
50 0 0 ACCEPT ESP
60 8 1088 ACCEPT NAT-T
10000 69 9516 DROP DEFAULT ACTION

6. Capture the arrival of the L2TP traffic on the ER external WAN interface:

sudo tcpdump -i eth0 -n udp dst port 500 or port 4500 or port 1701
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 I ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 R ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 I ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 R ident
IP 192.0.2.1.4500 > 203.0.113.1.4500: NONESP-encap: isakmp: phase 1 I ident[E]
IP 203.0.113.1.4500 > 192.0.2.1.4500: NONESP-encap: isakmp: phase 1 R ident[E]
IP 192.0.2.1.4500 > 203.0.113.1.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
IP 203.0.113.1.4500 > 192.0.2.1.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
IP 192.0.2.1.4500 > 203.0.113.1.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.4500 > 203.0.113.1.4500: UDP-encap: ESP(spi=0xc009fce1,seq=0x1), length 164
IP 192.0.2.1.4500 > 203.0.113.1.4500: UDP-encap: ESP(spi=0xc009fce1,seq=0x2), length 164
info_i_25x25.png Note: This is a live capture. If there is no output that means that the traffic is either not being generated on the client, or there is something blocking the traffic upstream. If there is output here and the connection is not establishing, verify the firewall rules above.

7. Capture the ER IPsec VPN logs:

sudo swanctl --log
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (408 bytes)
[IKE] 192.0.2.1 is initiating a Main Mode IKE_SA
[IKE] remote host is behind NAT
[CFG] looking for pre-shared key peer configs matching 203.0.113.1...192.0.2.1[172.16.0.10]
[CFG] selected peer config "remote-access"
[IKE] IKE_SA remote-access[15] established between ...
[IKE] CHILD_SA remote-access{5} established with SPIs ...
[KNL] 10.255.255.0 appeared on ppp0
info_i_25x25.png Note: This is also live capture. If there is no output that means that the traffic is either not being allowed through the firewall. Alternatively you can use the show vpn log | no-more command to view the entire IPsec log history.

8. The IPsec Security Associations (SAs):

show vpn ipsec sa
remote-access: #545, ESTABLISHED, IKEv1, b0a8c5df5ff1b225:a251946b15ebaaae
local '203.0.113.1' @ 203.0.113.1
remote '172.16.0.10' @ 192.0.2.1
AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384
established 351s ago
remote-access: #17, INSTALLED, TRANSPORT-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96
installed 8 ago
in cd49a319, 0 bytes, 0 packets
out 47a8a786, 0 bytes, 0 packets
local 76.237.8.193/32[udp/l2f]
remote 192.0.2.1/32[udp/l2f]

9. The remote access users and interfaces:

show vpn remote-access 
Active remote access VPN sessions:

User Time Proto Iface Remote IP TX pkt/byte RX pkt/byte
---------- --------- ----- ----- --------------- ------ ------ ------ ------
ubnt 00h01m22s L2TP l2tp0 192.168.100.240 4 58 86 7.4K

show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
l2tp0 10.255.255.0 u/u User: ubnt (192.168.100.240)

10. Send traffic over the tunnel from Host1 to Server1 and vice versa:

ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=63 time=45.5 ms

ping 172.16.1.10
PING 172.16.1.10 (172.16.1.10) 56(84) bytes of data.
64 bytes from 172.16.1.10: icmp_seq=1 ttl=63 time=43.9 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=63 time=44.1 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=63 time=44.4 ms

Related Articles


Back to Top