Blog

This blog post is part of a series on EdgeRouter Lite. You may want to check them all out!

Introduction

In my How to configure EdgeRouter Lite via CLI – Part 2 post, there is an L2TP via IPsec section. The commands shown in that blog post works great. However, there are security concerns with that configuration. The remote-access VPN configuration uses pre-shared secret for machine authentication and user authentication with no two-factor authentication (2FA). In this post, I will demonstrate how to harden remote-access VPN connectivity on EdgeRouter Lite.

User Authentication with 2FA

As mentioned in my how-to configure guide, I prefer L2TP over IPsec, so this post will only cover that. The configuration demonstrated here requires a RADIUS server, such as FreeRADIUS. Check my blog post about it if you want to create your own. If you chose the local Google Authenticator route, there might be a way to tie that with user authentication. That is, however, out of the scope of this post.

The EdgeOS has two L2TP modes for user authentication, local and RADIUS. In my how-to guide, it showed the use of the local account which is separate from device management. As previously discussed, username and password are no longer considered secure today. That said, we’re going to add another factor of authentication to the account.

EdgeOS Commands

The first command is to change user authentication mode to RADIUS.

set vpn l2tp remote-access authentication mode radius

The second command is to point the device to the RADIUS server and enter the key you want to use.

set vpn l2tp remote-access authentication radius-server 192.168.250.250 key supersecretkey

The last command is to change the default protocol from MS-CHAPv2 to PAP. Unfortunately, Google Authenticator will only work with PAP, as far as I know.

set vpn l2tp remote-access authentication require pap

Don’t forget to commit and save the configuration. Issue the commit;save command.

FreeRADIUS Configuration

In my FreeRADIUS blog post, there were only a few lines that needed to be changed or added to the config files. Aside from those modifications the files were left in the default state. That’s okay for the most part. However, when we try to access VPN, it takes a bit longer than using the local account. In this section, we’re going to make some optimizations to speed up the process of authentication.

I am a FreeRADIUS newbie, so I do not know what all of these lines mean, but I commented them out to speed up the process of authentication. I just looked at the debug using sudo freeradius -X command and tried to interpret what it was saying. The lines that included noop, I figured they are not needed for my environment, so I commented them out. Every time I made the change, I tested my VPN to make sure I was able to log in still. If you are currently using or going to use this FreeRADIUS instance for other purposes, then be careful of what you comment out because it may break. Remember, I only use this for remote access VPN and device authentication.

Edit the /etc/freeradius/sites-enabled/default file.

$ sudo vi /etc/freeradius/sites-enabled/default

Find the following and comment them out.

authorize {
#      chap
#      mschap
#      suffix
#      eap {
#              ok = return
#      }
#      expiration
#      logintime
#      pap
authenticate {
#      Auth-Type PAP {
#              pap
#      }
#      Auth-Type CHAP {
#              chap
#      }
#      Auth-Type MS-CHAP {
#              mschap
#      }
#      digest
#      eap
preacct {
#      suffix
#      files
accounting {
#      exec
post-auth {
#      exec

Next step is to edit the clients.conf file. From what I can tell, this is kind of like an ACL. If you do not add the router’s source IP address, then FreeRADIUS will ignore the traffic from the router. Once you open the file using VI or your favorite text editor, look for the client localhost { line and add the lines listed below.

$ sudo vi /etc/freeradius/clients.conf
client rtr {
        ipaddr = 192.168.1.1
        secret = secretkey
}
client localhost {

Since we made changes to the files, we need to restart the service for it to take effect.

$ sudo service freeradius restart

Verification

Now, go ahead and test your VPN connectivity to see if it works. If everything works, then you can now delete the local account from the configuration. Remember, the format for the password is password+TOTP.

delete vpn l2tp remote-access authentication local-users username unique-username-here password your-unique-password-here

Troubleshooting

When you are troubleshooting FreeRADIUS, it is very helpful to use the freeradius -X command. This helped me figure out some issues that I’ve encountered when setting this up. This command may be different in other Linux distro, though. Just check the documentation for the right command. From what I can tell, all Debian-based Linux distro uses this command.

Before you can issue the debug command, you need to stop FreeRADIUS service first or you will get an error, as shown below.

$ sudo freeradius -X
<-- Output omitted for brevity -->
Failed binding to authentication address * port 1812: Address already in use
/etc/freeradius/radiusd.conf[273]: Error binding to port for 0.0.0.0 port 1812
$ sudo service freeradius stop
$ sudo freeradius -X
<-- Output omitted for brevity -->
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.

Once you’re done with troubleshooting, make sure to start the service back up with sudo service freeradius start command.

Final Words

The problem with local authentication is that we need to enter user account details within EdgeOS. That said, anyone who has admin-level access on EdgeOS will be able to view the password of the users. Changing the remote access VPN authentication from local to RADIUS is a more secure option. On top of that, we can add another factor of authentication.

For the most part, this is secure enough. In fact, I’ve seen a lot of organizations that use a similar setup. However, some organizations or people want to implement the securest method possible for their remote access VPN. That said, they need to implement certificate-based machine authentication. Heck, they may even combine both 2FA and certificate-based machine authentication for maximum security.

If I ever get the L2TP over IPsec working using certificates, then I will cover it in my next blog post. I know it’s possible, but my client is stuck in IKE Phase 1. The problem is most likely my certificates.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

This blog post is part of a series on EdgeRouter Lite. You may want to check them all out!

Introduction

I focused on authentication method in the first two posts of this EdgeRouter Lite series. In today’s post, I will focus on access restriction to the management plane. To accomplish this access restriction, we need to create firewall policies on the router and apply it to LAN and sub-interfaces. This post will show what you need for the firewall policy.

Management ACL

While restricting management services to listen on a single address, it is also a good practice to restrict addresses or networks allowed to reach it. The firewall on EdgeOS allows users the creation of address groups and network groups. The groups allow users include more than one address in the firewall policy. Without further ado, below is an example of a firewall policy that one can apply to EdgeRouter Lite.

Firewall group

We need to gather the source IP addresses or network prefixes that will be allowed to connect to the EdgeRouter Lite. It is good practice that these hosts are one of the most secure computers in the network.  We do not want the bad guys taking control of our router since all traffic traverses through it. For example, my Linux hosts have 2FA enabled for both SSH and console access.

The address-group allows users to add multiple IP addresses.

set firewall group address-group SSH-TRUSTED address 192.168.254.100
set firewall group address-group SSH-TRUSTED address 192.168.254.101

The network-group allows users to add network prefixes.

set firewall group network-group GUI-TRUSTED network 192.168.253.0/24
set firewall group network-group GUI-TRUSTED network 192.168.254.0/24

Firewall policy

Once we’ve created the firewall group, we are now ready to create the firewall rules.

The first three lines are what a lot of people will call this as a catch-all rule. Any traffic not defined in our firewall policy will fall under this rule.

set firewall name LAN-LOCAL default-action drop
set firewall name LAN-LOCAL description 'LAN IPv4 inbound traffic to the router'
set firewall name LAN-LOCAL enable-default-log

The next firewall rule is unnecessary, but I like to add it in the beginning. In my environment, this rule has one of the lowest numbers, so it is safe to move it at the end of the firewall policy if you feel so inclined. Alternatively, do not add this rule since the catch-all rule will drop this traffic.

set firewall name LAN-LOCAL rule 10 action drop
set firewall name LAN-LOCAL rule 10 description 'Drop invalid state'
set firewall name LAN-LOCAL rule 10 log disable
set firewall name LAN-LOCAL rule 10 state invalid enable

I will leave the next rule at your discretion. Some people like to allow ICMP for troubleshooting purposes and some people do not.

set firewall name LAN-LOCAL rule 20 action accept
set firewall name LAN-LOCAL rule 20 description 'Allow ICMP'
set firewall name LAN-LOCAL rule 20 log disable
set firewall name LAN-LOCAL rule 20 protocol icmp

The next rule depends if you run SNMP or not. I run the free PRTG Network Monitor in my environment, so I have to add it.

set firewall name LAN-LOCAL rule 30 action accept
set firewall name LAN-LOCAL rule 30 description 'Allow SNMP'
set firewall name LAN-LOCAL rule 30 destination port 161
set firewall name LAN-LOCAL rule 30 log disable
set firewall name LAN-LOCAL rule 30 protocol udp
set firewall name LAN-LOCAL rule 30 source address 192.168.200.200

These next rules are what we need to restrict source IP addresses or network prefixes that can connect to the EdgeRouter Lite. If you disable GUI access then there is no point in adding firewall rules for both HTTP and HTTPS.

set firewall name LAN-LOCAL rule 40 action accept
set firewall name LAN-LOCAL rule 40 description 'Allow SSH'
set firewall name LAN-LOCAL rule 40 destination port 22
set firewall name LAN-LOCAL rule 40 log disable
set firewall name LAN-LOCAL rule 40 protocol tcp
set firewall name LAN-LOCAL rule 40 source group address-group SSH-TRUSTED
set firewall name LAN-LOCAL rule 50 action accept
set firewall name LAN-LOCAL rule 50 description 'Allow HTTPS'
set firewall name LAN-LOCAL rule 50 destination port 443
set firewall name LAN-LOCAL rule 50 log disable
set firewall name LAN-LOCAL rule 50 protocol tcp
set firewall name LAN-LOCAL rule 50 source group network-group GUI-TRUSTED
set firewall name LAN-LOCAL rule 60 action accept
set firewall name LAN-LOCAL rule 60 description 'Allow HTTP'
set firewall name LAN-LOCAL rule 60 destination port 80
set firewall name LAN-LOCAL rule 60 log disable
set firewall name LAN-LOCAL rule 60 protocol tcp
set firewall name LAN-LOCAL rule 60 source group network-group GUI-TRUSTED

The last rule allows any traffic that is in established or related state. Check this site to understand the states.

set firewall name LAN-LOCAL rule 70 action accept
set firewall name LAN-LOCAL rule 70 description 'Allow Established'
set firewall name LAN-LOCAL rule 70 log disable
set firewall name LAN-LOCAL rule 70 protocol all
set firewall name LAN-LOCAL rule 70 state established enable
set firewall name LAN-LOCAL rule 70 state related enable

Apply the firewall policy

Now, we need to apply the firewall rule to all your LAN interfaces including sub-interfaces.

set interfaces ethernet eth1 firewall local name LAN-LOCAL
set interfaces ethernet eth2 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 10 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 50 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 100 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 200 firewall local name LAN-LOCAL

Save config

Now, we need to save the configuration by issuing commit;save command.

Verification

Try connecting to EdgeRouter Lite without logging out from your current SSH or secure HTTP connection. This ensures that you still have access to the router just in case there’s a mistake with the ACL. If you have a Network Management System (NMS), make sure that SNMP is working as well.

Final Words

Any traffic destined to the EdgeRouter Lite must be restricted. While we did it on the WAN side, we also need to secure the LAN side. As much as possible, the allowed list must be limited. Only systems that must have router access should be on the list. Finally, computers on the list should have great security controls to keep it from being compromised.

The next blog post, I am going to talk about securing the remote access VPN. The blog post will address the security concerns on my how to configure EdgeRouter Lite guide.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.