Seth Forshee’s Blog

EdgeRouter: Accept OpenVPN Connections on Multiple Ports

2016-09-28T00:00:00+00:00

Since different networks frequently have different restrictions on what ports are allowed to access the internet, it’s useful to have OpenVPN listening on multiple ports for incoming connections. However OpenVPN does not support listening on multiple ports from a single instance of the server. The usual advice is to run separate instances of OpenVPN for each port.

This has some obvious disadvantages - more configurations to manage, more subnets, more firewall rules, etc. Fortunately there’s another way we can do this, by having the router translate the destination port for incoming packets to a different port, commonly called port forwarding.

The Ubiquiti EdgeRouter products offer two different configuration interfaces for setting this up, destination NAT (DNAT) and port forwarding. I’ve chosen to use DNAT, simply because I wanted to play around with the NAT functionality.

Which Ports?

Before starting we need to know which ports we want OpenVPN to listen on. This will vary depending on the situation. I’m going to assume a typical home user who wants to be able to access their home network from various locations and who does not run a public facing web server from their network.

Any network which allows general web access must allow clients to establish connections over TCP ports 80 and 443, which respectively are the standard ports for HTTP and HTTPS. Therefore setting up OpenVPN to listen on these ports will allow access from practically any network. In this example I’ll assume that OpenVPN is listening on TCP port 443 and we want to also forward connections on port 80.

Setting Up DNAT

The instructions here assume that you already have OpenVPN up and running on the EdgeRouter. Please see here for more information about OpenVPN setup. That post also notes a pitfall of running OpenVPN on port 443 and how to handle it.

The following commands set up a DNAT rule to forward incoming connections on port 80 to port 443.

$ configure
# edit service nat rule <rule-number>
# set description "Port forward for OpenVPN"
# set type destination
# set inbound-interface <wan-iface>
# set destination port 80
# set inside-address port 443
# set protocol tcp

Fill in the rule number and the WAN interface. The rule number is only going to be significant if you have other DNAT rules, as rules will be executed sequentially. I found this article from Ubiquiti which states that source/masquerade NAT rules must be numbered 5000 or higher, but I didn’t find anything stating a similar limitation on the number of DNAT rules. It’s probably a good idea to leave some space in case you later need to insert rules before this one, so something like 100 should be fine. You can always change the rule number later by copying the rule to a new one and deleting the original.

After committing these changes it will be possible to connect to OpenVPN on both TCP ports 80 and 443. You might think that the firewall rules need updates to allow incoming TCP connections on port 80, but this isn’t the case. DNAT happens before the firewall, so a rule is only needed for the translated address.

Limitations

There is one significant limitation to this approach - it’s not possible to forward TCP connections to a UDP port, or vice versa, since they are different protocols. If you wish to accept both TCP and UDP connections it is necessary to run two OpenVPN instances. In that case the rule above can be modified to specify tcp_udp for the protocol so that connections using either protocol will be forwarded.

Fixing 256-color Support with tmux in terminator

2016-05-26T00:00:00+00:00

I use terminator for my terminal emulator. Generally everything works well, but one problem has been bothering me recently. My vim color scheme shows up fine in terminator but not from tmux within terminator. Everything is okay when using tmux in gnome-terminal though, so it seems to be the combination of tmux and terminator that is problematic.

After a little digging I found out that this is due to terminator setting TERM=xterm in the environment, causing tmux to think that the terminal doesn’t support 256 colors. This is easily verified by the fact that running TERM=xterm-256color tmux fixes the issue.

If terminator supports 256 colors, why is it setting TERM to xterm instead of xterm-256color? I didn’t really dig into it, but the gory details are here for anyone who is interested. The tl;dr is that it doesn’t look like it will get fixed soon.

But since the terminal really does support 256 colors, a simple workaround is to just override TERM in the environment. This should only be done for terminator though, we don’t want to mess with the variable as set by other terminal emulators.

This can be done in the terminator configuration. It’s part of the profile settings though, so if you have more than one profile it needs to be done for each one.

In the gui you can open the preferences and navigate to Profiles -> <profile> -> Command. Check the box to run a custom command then enter TERM=xterm-256color bash -l as the custom command (assuming you use bash, if not substitute your shell). Or open ~/.config/terminator/config and add this line to each profile:

custom_command = TERM=xterm-256color bash -l

Newly launched terminator windows will have TERM=xterm-256color.

Ubiquiti EdgeRouter Lite Setup Part 6: Odds and Ends

2016-03-22T00:00:00+00:00

In this final post on configuring the ERL we’ll cover some miscellaneous items that don’t warrant a full post on their own. See part 1 for a list of all posts in this series.

Dynamic DNS

The ERL can automatically update your IP address with a number of dynamic DNS providers. I’m using the following configuration with DNS-O-Matic:

$ configure
# show service dns dynamic 
 interface eth0.2 {
     service dyndns {
         host-name all.dnsomatic.com
         login <username>
         password <password>
         server updates.dnsomatic.com
     }
 }

Static DHCP Mappings

Sometimes it’s useful to assign known IPv4 addresses to specific machines. This example demonstrates how to set this up.

$ configure
# edit service dhcp-server shared-network-name <name> subnet <subnet>
# set static-mapping <name> mac-address <mac-address>
# set static-mapping <name> ip-address <ip-address>

Changing the Host Name

The default host name for the ERL is ubnt, but this can be easily changed.

$ configure
# set system host-name <name>

Google Fiber

According to the information available on various forums and blogs, in order to get maximum performance when using the ERL in place of the Google Fiber network box traffic in and out of the WAN interface must be tagged for VLAN 2 and have the VLAN priority set to 3, and hardware offloading should be enabled. I’ve never tried using the ERL with any other configuration, but I can confirm that I’m seeing good speeds with this configuration.

To apply these settings, delete most other settings from the WAN interface (besides duplex auto and speed auto) and do the following:

$ configure
# edit interfaces ethernet <iface> vif 2
# set description "Google Fiber"
# set address dhcp
# set egress-qos 0:3
# top
# set system offload ipv4 forwarding enable
# set system offload ipv4 vlan enable
# set system offload ipv6 forwarding enable
# set system offload ipv6 vlan enable

You’ll also need to apply your IPv6 prefix delegation settings to the virtual interface.

Staying Up to Date

It’s a good idea to keep your router firmware up to date to ensure that you have all the latest security fixes. I haven’t found any way to receive emails or similar when new firmware is made available, but firmware announcements are posted to the EdgeMax Updates Blog.

Conclusion

In my opinion Ubiquiti’s EdgeRouter Lite is a very nice step up from the typical home or small office router for those who want more control over their networks. These posts have described configuration of some of the most common features needed for a basic home or small office network.

Ubiquiti EdgeRouter Lite Setup Part 5: OpenVPN Setup

2016-03-16T00:00:00+00:00

In previous posts we’ve covered everything required to set up a network with multiple VLANs and IPv6 (see part 1 for a list of all posts in this series). Today we’re going to talk about setting up an OpenVPN server on the ERL.

If you aren’t familiar with VPNs, think of them as encrypted tunnels used to connect computers over the internet. Common uses for VPNs include:

Providing privacy while using public networks, especially open public wifi hotspots.
Enabling secure, remote access to LANs, connecting remote networks. Corporations often use this to allow employees to access the corporate network remotely.
Connecting networks in multiple, fixed locations. For example a business with multiple offices might use this to securely connect together the various office networks via the internet.

The VPN setup described here can be used for the first two use cases above but not for the third.

There are several protocols which can be used to set up a VPN, including PPTP, L2TP, SSTP, and OpenVPN. I’ve chosen OpenVPN here because it’s secure, flexible, and open source. The paticular configuration is very specific to my needs and level of paranioa. Consult the OpenVPN documentation to help you modify this setup for your needs.

Generating Certificates

OpenVPN uses public key cryptography in essentially the same way it’s used to make secure connections to websites. This means we need a public key infrastructure capable of generating signed public/private key pairs, which in turn means we need to create our own certificate authority (CA). There’s a script on the ERL to help us do that.

$ sudo -s
# cd /usr/lib/ssl/misc
# ./CA.sh -newca

You’ll be asked a number of questions during the process, and skipping them may cause it to fail. Just answer the best you can. This is going to happen several times while setting up the certificates.

If you supply a password here, make sure you remember it. You’re going to need it! Of course if you forget it you can always start the process over again at the beginning.

Once this completes you’ll have a demoCA directory containing a number of files. The important ones are cakey.pem, which is the private key for your CA, and cacert.pem, which is the public key.

Next we’ll generate a public/private keypair for the OpenVPN server.

# ./CA.sh -newreq
# ./CA.sh -sign

This will generate two files, newkey.pem and newcert.pem, which are respectively the private and public halves of your server certificate.

Now we’re going to move all of these key files to /config/auth/. This will ensure that they’re preserved across firmware upgrades and include in your configuration backups.

# cp demoCA/cacert.pem demoCA/private/cakey.pem /config/auth
# mv newcert.pem /config/auth/host.pem
# mv newkey.pem /config/auth/host.key

Next we’ll generate a Diffie-Hellman parameter file. This will allow clients and the server to generate shared session keys without ever having to transmit that key over the internet, so even if someone compromised the server certificate they would be unable to decrypt session traffic. I use a key size of 2048, though 1024 is more common and probably safe (though I don’t claim to be a crypto expert).

# openssl dhparam -out /config/auth/dhp.pem -2 2048

This is going to take a while, so go get a cup of your favorite beverage. No need to hurry.

Once that’s completed you’ll need keys for clients, preferably one set per client.

# ./CA.sh -newreq
# ./CA.sh -sign
# mv newcert.pem /config/auth/client1.pem
# mv newkey.pem /config/auth/client1.key

At this point I note that some other guides state that you should remove the password from your client key files. I honestly can’t remember whether or not I did this, or maybe I just didn’t supply a password for the client certificates. Anyway, here’s the command to do this if you’re having issues because the client keys have a password, or if you’re just getting annoyed at entering the password each time you connect:

# openssl rsa -in client1.key -out client1_nopass.key

You’ll need to copy the .pem files to the respective clients to allow them to make connections.

OpenVPN Server Setup

Now it’s time to set up the OpenVPN server on the ERL. This is done by creating a new interface. You’ll also need a new IPv4 subnet for the VPN; I use 192.168.200.0/24 here.

You’ll also need to make decisions about which port to use, whether to use tcp or udp, which routes to push, etc. For this example I’ll use tcp on port 443, which sort of disguises the traffic as normal SSL (useful because SSL connections are never blocked by network admins). I’ll push a route to allow communication with clients in the office network.

Update: As pointed out in the comments port 443 conflicts with using SSL for the web gui. Your options to solve this are to either use a different port for the web interface (the serivce gui https-port setting controls this) or a different port for the VPN.

$ configure
# edit interfaces openvpn vtun0
# set description OpenVPN
# set mode server
# set local-port 443
# set protocol tcp-passive
# set server subnet 192.168.200.0/24
# set server topology subnet
# set server push-route 192.168.103.0/24
# set tls ca-cert-file /config/auth/cacert.pem
# set tls cert-file /config/auth/host.pem
# set tls dh-file /config/auth/dhp.pem
# set tls key-file /config/auth/host.key

Firewall Setup

Now we need to set up a firewall zone for the VPN and write rules for this zone. In this setup the VPN is really just an extension of the office LAN, so for the most part we can just reuse the same rules used for the office LAN zone. There are a handful of cases where this isn’t possible though:

WAN to local: A rule is needed here to allow incoming tcp connections on port 443.
VPN to office LAN: All traffic is allowed.
Office LAN to VPN: All traffic is allowed.

Refer back to part 2 for help setting up the firewall.

Final Steps and Testing

The OpenVPN server hands out IP addresses to clients, so there’s no need to set up DHCP for the VPN subnet. You may or may not want to set up DNS to listen on the vtun0 interface, depending on your needs.

Now it’s time to save everything and try it out.

# commit
# save

You’ll need to configure your client machine(s) to connect using the client certificate(s) we generated earlier. The steps for doing this vary depending on your OS; please consult the OpenVPN documentation for help.

For testing it’s ideal to try and connect from outside your network, e.g. by tethering to a phone. But for this setup it’s also possible to test by trying to use the VPN to access the office LAN from the home LAN. Just be sure you’ve set up firewall rules to allow clients on the home LAN to connect to the OpenVPN server on the router.

Hardening

This section isn’t essential, but I do recommend it.

The OpenVPN hardening page covers various ways to improve the security of OpenVPN. It’s useful to read through these. The only one that I’m going to cover here is TLS auth.

The TLS auth option is pretty cool. It makes it so that the OpenVPN server will not respond to packets unless those packets have a valid signature from a pre-shared key. This makes it so that someone doing a port scan of your public IP address will not see that the OpenVPN port is accepting connections. It also provides other benefits described on the hardening page.

Setting this up is pretty simple. First you need to generate the pre-shared key.

  
$ openvpn --genkey --secret ta.key

Next, copy the key to /config/auth on the ERL and to all client machines. Then set up the OpenVPN server to use the --tls-auth option.

  
$ configure  
# set interfaces openvpn vtun0 openvpn-option "--tls-auth /config/auth/openvpn/ta.key 0"  
# commit  
# save

Finally, configure clients to pass the --tls-auth ta.key 1 option to OpenVPN.

Update 2016-12-30:

Since writing this post I’ve employed a few addtional hardening options for OpenVPN:

Drop root privileges after OpenVPN initialization. This is done by passing the --user nobody --group nogroup options to OpenVPN. Additionally the --persist-key --persist-tun options should be used to avoid the need for privileges on soft restart.
Use AES256 for the cipher and SHA256 for the message digest instead of the defaults (Blowfish/SHA1). Note that this may impact performance.

Use the following commands to enable these options.

  
$ configure  
# edit interfaces openvpn vtun0
# set openvpn-option "--user nobody"
# set openvpn-option "--group nogroup"
# set openvpn-option --persist-key
# set openvpn-option --persist-tun
# set encryption aes256
# set hash sha256
# commit  
# save

You will also need to set the cipher and message digest appropriately in your client configuration.

Conclusion

In this post we’ve covered one fairly common scenario for setting up an OpenVPN server on the ERL. OpenVPN is incredibly flexible though, so if your needs aren’t completely covered by this guide there’s a pretty good chance that you just need to tweak the configuration.

The next post will wrap up this series by covering various useful odds and ends that we haven’t touched on yet.

Ubiquiti EdgeRouter Lite Setup Part 4: IPv6 Setup

2016-03-08T00:00:00+00:00

At this point we’ve done basic setup of the ERL, configured a zone-based firewall and set up flexible network partitioning using VLANs. But we’re still only supplying an IPv4 network to clients. In this post we’re going to learn about deploying IPv6.

To my knowledge DHCPv6 prefix delegation is widely supported among ISPs that provide native IPv6. That’s what I describe here; check with your ISP for specifics about using IPv6 on their network.

If your ISP doesn’t support IPv6 at all a good option is a 6to4 service like tunnelbroker.net. I won’t describe setting that up here, but instructions can be found elsewhere.

DHCPv6 and Prefix Delegation

RFC 3633 defines a mechanism by which DHCPv6 can be used to delegate a network address prefix to a network. This is known as prefix delegation. The router can then assign addresses to clients within the network using either DHCPv6 or stateless address autoconfiguraton (SLAAC). With SLAAC the router advertises a prefix to clients, and clients pick their own address within that network. This example will use SLAAC.

WAN Setup

The first step in configuring the ERL is to set up the WAN interface to request a prefix via DHCPv6. Our network is divided into multiple LANs, so we’ll divide up the assigned prefix into smaller networks that can be advertised on each lan, assigning the ::1 address in each network to the virtual interface in the ERL.

$ configure
# edit interfaces ethernet eth0
# set dhcpv6-pd rapid-commit enable
# set dhcpv6-pd pd 1 prefix-length /56
# set dhcpv6-pd pd 1 interface eth2.1 service slaac
# set dhcpv6-pd pd 1 interface eth2.1 prefix-id 1
# set dhcpv6-pd pd 1 interface eth2.1 host-address ::1
# set dhcpv6-pd pd 1 interface eth2.2 service slaac
# set dhcpv6-pd pd 1 interface eth2.2 prefix-id 2
# set dhcpv6-pd pd 1 interface eth2.2 host-address ::1
# set dhcpv6-pd pd 1 interface eth2.3 service slaac
# set dhcpv6-pd pd 1 interface eth2.3 prefix-id 3
# set dhcpv6-pd pd 1 interface eth2.3 host-address ::1
# top

The prefix length is determined by your ISP, so you will need to check with them to determine the correct value.

LAN Setup

Update: There is a much simpler way to get router advertisements on your LANs than what I described in my original instructions. Simply do this:

# edit interfaces ethernet eth2 vif 1
# set ipv6 address autoconf
# set ipv6 dup-addr-detect-transmits 1

I can’t recall now why I didn’t do it this way originally. Possibly it’s a legacy of having previously used a 6to4 tunnel. Anyway, I’d suggest you try this first, and refer to the original instructions (below) only if you need to customize the router advertisements.

Original Instructions:

Now each vif must be configured to advertise its assigned IPv6 prefix to clients.

# edit interfaces ethernet eth2 vif 1
# set ipv6 dup-addr-detect-transmits 1
# set ipv6 router-advert cur-hop-limit 64
# set ipv6 router-advert link-mtu 0
# set ipv6 router-advert managed-flag false
# set ipv6 router-advert max-interval 600
# set ipv6 router-advert other-config-flag false
# set ipv6 router-advert prefix ::/64 autonomous-flag true
# set ipv6 router-advert prefix ::/64 on-link-flag true
# set ipv6 router-advert prefix ::/64 valid-lifetime 2592000
# set ipv6 router-advert reachable-time 0
# set ipv6 router-advert retrans-timer 0
# set ipv6 router-advert sent-advert true

Again here the size of your prefix may depend on the size of the prefix assigned by your ISP. Since my ISP assigns a /56 prefix I have 256 /64 networks that I can assign to my subnets.

Repeat these steps for the other virtual interfaces on eth2.

Potential Problems

When I was originally playing with this I found that either the ERL or my ISP or both were a bit finicky when it came to making IPV6 changes on the ERL. Here are a few tips for some scenaios I encountered:

If you’re replacing a router supplied by your ISP it may have already requested a prefix, and your ISP may not allow the ERL to request a prefix until that lease has expired. If you’re having trouble getting a prefix and nothing seems to be working, you might just need to wait.
In some cases the ERL seemed to get a bit confused after I changed some IPv6-related settings. Rebooting the ERL always cleared this up.
I ended up with cases where, after changing the prefixes I was assigning to my LANs, clients ended up with IPv6 addresses in both the old and new prefixes. Disconnecting then reconnecting clients to the network generally straightened things out. If all else fails you can always reboot the client.

Conclusion

Hopefully you find these instructions helpful, but if your situation turns out to be different from mine there’s a lot of information to be found in forums. Just fire up your favorite search engine and you’re likely to find others who have already solved your problems.

At this point we’ve covered everything for a reasonably complete network setup. From here we’ll start exploring some more specialized topics, starting with setting up an OpenVPN server on the ERL.

Ubiquiti EdgeRouter Lite Setup Part 3: VLAN Setup

2016-03-04T00:00:00+00:00

Those who have followed along with parts 1 and 2 of this series should now have an ERL configuration with one WAN and one LAN interface and a zone-based firewall. Let’s take another look at our example network configuration diagram.

Rather than the single LAN we have now, this shows separate home and office LANs. It also shows a wireless AP which will supply wireless networks for both LANs.

One way to separate the home and office networks would be to put them on different interfaces of the ERL, e.g. the home LAN on eth1 and the office LAN on eth2. This would work but has a some disadvantages - reconfiguring the network might involve rewiring, and each network needs its own wireless AP.

A more flexible option is to use virtual LANs (VLANs). With VLANs the networking equipment provides a logical separation of networks which can easily be reconfigured in software. A single interconnect can carry traffic for multiple VLANs using 802.1q VLAN tagging, which allows deploying a single AP which serves wireless networks for both LANs or even multiple APs throughout the building all serving multiple wireless networks.

Using VLANs does require that at least some of your other networking equipment support VLANs. In a small network a single managed switch is sufficient, and wireless APs need to support defining multiple SSIDs with VLAN tagging.

In this post we’ll learn how to set up VLANs on the ERL. A VLAN deployment will also require configuring switches and wireless APs, but exactly how to do this is hardware-specific and thus will not be covered here.

Adding VLANs

A VLAN is created by adding a virtual interfaces or vif to one of the physical interfaces. For our network we’ll define three VLANs. Each VLAN will need its own pool of addresses to assign to clients. For this example we’ll use:

VLAN 1: Management network. This is the network used for communication between the network hardware. Subnet: 192.168.101.0/24.
VLAN 2: Home network. Subnet: 192.168.102.0/24.
VLAN 3: Office network. Subnet: 192.168.103.0/24.

VLAN Configuration

We’ll configure the management LAN as an example. First we need to add the vif to eth2:

$ configure
# edit interfaces ethernet eth2
# set vif 1 description "Management VLAN"
# set vif 1 address 192.168.101.1/24
# top

Next, set up DHCP and DNS for this network.

# edit service dhcp-server shared-network-name mgmt
# set authoritative disable
# set subnet 192.168.101.0/24 default-router 192.168.101.1
# set subnet 192.168.101.0/24 dns-server 192.168.101.1
# set subnet 192.168.101.0/24 lease 86400
# set subnet 192.168.101.0/24 start 192.168.101.150 stop 192.168.101.254
# top
# set service dns forwarding listen-on eth2.1

Repeat this procedure for the home and office VLANs.

Firewall Rules

Firewall rules and zone policy also need to be defined for the management zone. I won’t cover this in detail here; refer to part 2 for guidance.

Deleting the Old Configuration

Once the VLAN configuration has been verified to be working with other networking equipment, much of the old configuration for the LAN is likely no longer needed. It should be safe to delete the IP address for eth2 and the DHCP settings, DNS settings, and zone policy for the old LAN network. Any firewall rulesets that are no longer used can also be deleted. Make sure that you delete only the rules for the eth2 interface itself and not for its VLANs. Also be sure that the firewall rules allow access to the router configuration from at least one of the VLANs, otherwise you may find yourself locked out!

Guest/IoT VLAN

Though this isn’t included in the example network we’re setting up, it’s definitely worth mentioning.

Setting up isolated wireless networks for guests and/or internet of things (IoT) devices is a really good idea. Guests could be bringing compromised devices into your network, and IoT devices are infamous for their poor security practices. Unless you have a specific reason that the device needs to be on the same network as your other machines (e.g. a wireless printer) it’s better to put them on an isolated network.

Using the information above it is strightforward to add one or more additional VLANs for these devices. Set up the vlan similarly to the one above, set up DHCP with an unused range of IPv4 addresses, add a new firewal zone for the network, and configure the firewall so that all trafic to and from the zone is dropped except for WAN traffic. Pro tip: If the default action for your zones is drop you don’t actually need to explicitly add rules to drop traffic between two zones.

Conclusion

That’s it for our brief overview of setting up VLANs on the ERL. In part 4 we’ll talk about deploying IPv6 on the ERL.

Ubiquiti EdgeRouter Lite Setup Part 2: Firewall Setup

2016-03-02T00:00:00+00:00

In part 1 we covered the basics of setting up the ERL for one WAN interface and one LAN interface with a basic firewall on the WAN interface. But isolating our internal networks against bad actors on the outside is one of the most important functions of a router, so let’s explore a more robust firewall configuration.

ACL vs. Zone Based Firewall

The default firewall setup on the ERL (and the only one supported via the web client) allows defining firewalls as sets of ACL rules on a per-interface and per-direction basis. But the ERL also supports zone-based firewalls, which work by dividing your network into zones and matching rules based on source and destination zones. For a pretty thorough comparison of ACL versus zone-based firewall, I suggest going here. The basic idea behind a zone-based firewall is as follows:

You define zones for your network. A common set of zones might be WAN, LAN, and DMZ.
You assign one or more interfaces to each zone.
You set up rules which match based on source and destination zones.

While an ACL firewall can be easier to set up for simple networks such as the one in this example, a zone-based firewall is conceptually simpler (in my opinion at least) and less susceptible to the sorts of mistakes that can open up your network to the outside.

Setting Up a Zone Based Firewall

The approach I’ve taken is based on this article, and I recommend reading it before proceeding. The link to the example configuration file in that article is broken however, luckily someone was kind enough to post a copy here.

Let’s convert the firewall we created in part 1 to a roughly equivalent zone-based firewall. In the end the result will in fact be much more robust than the ACL firewall.

Define Zones and Allowed Connections

The first step is to determine what our zones are and what connections will be permited for each pair of source and destination zones.

In this simple setup we have a WAN zone for the connection to the internet and a LAN zone for our internal LAN. We also need to define one more zone, named local, for connections to the router itself (DHCP, DNS, ssh, etc.).

Three zones gives us six <source>,<destination> zone pairs. A reasonable initial set of rules for traffic to allow between the zones is:

WAN to LAN: Allow only traffic for established connections.
WAN to local: Allow only traffic for established connections.
LAN to WAN: Drop invalid state packets, allow all other traffic.
LAN to local: Allow traffic for established connections. Also allow new ICMP, DHCP, DNS, ssh, and HTTP/HTTPS connections.
local to WAN: Drop invalid state packets, allow all other traffic.
local to LAN: Drop invalid state packets, allow all other traffic.

Create Firewall Rulesets

Now we need to translate the list of permissible traffic into firewall rules.

The article linked to above suggests defining two sets of rules for every <source>,<destination> pair, using the naming convention <source>-<destination> for IPv4 and <source>-<destination>-6 for IPv6. I generally follow this suggestion, but it results in quite a few identical rulesets, as you can see from the list above. Therefore I define a few “standard” rulesets for these rather than having redundant rules. Let’s write these rulesets first.

The most basic of these is what I call the allow established, drop invalid ruleset. For performance reasons these rules form the basis of all rulesets, but often they are the only rules needed. The following commands in the CLI will create this ruleset for IPv4.

$ configure
# edit firewall name allow-est-drop-inv
# set default-action drop
# set enable-default-log
# set rule 1 action accept
# set rule 1 state established enable
# set rule 1 state related enable
# set rule 2 action drop
# set rule 2 log enable
# set rule 2 state invalid enable
# top

We need an equivalent rule for IPv6, but here we need to additionally allow ICMP connections.

# edit firewall ipv6-name allow-est-drop-inv-6
# set default-action drop
# set enable-default-log
# set rule 1 action accept
# set rule 1 state established enable
# set rule 1 state related enable
# set rule 2 action drop
# set rule 2 log enable
# set rule 2 state invalid enable
# set rule 100 action accept
# set rule 100 protocol ipv6-icmp
# top

The other repeated case we have is the allow all connections ruleset. To save some typing we can start off by making a copy of the allow-est-drop-invalid rulesets, then simply change the default action to accept and disable logging for the default rule.

# edit firewall
# copy name allow-est-drop-inv to name allow-all
# set name allow-all default-action accept
# delete name allow-all enable-default-log
# top

Repeat these steps to create a allow-all-6 ruleset.

We have only one ruleset left to create now, for connections from the LAN to the router. For IPv4 this looks like:

# edit firewall
# copy name allow-est-drop-inv to name lan-local
# edit name lan-local
# set rule 100 action accept
# set rule 100 protocol icmp
# set rule 200 description "Allow HTTP/HTTPS"
# set rule 200 action accept
# set rule 200 destination port 80,443
# set rule 200 protocol tcp
# set rule 600 description "Allow DNS"
# set rule 600 action accept
# set rule 600 destination port 53
# set rule 600 protocol tcp_udp
# set rule 700 description "Allow DHCP"
# set rule 700 action accept
# set rule 700 destination port 67,68
# set rule 700 protocol udp
# set rule 800 description "Allow SSH"
# set rule 800 action accept
# set rule 800 destination port 22
# set rule 800 protocol tcp
# top

This should be done for IPv6 as well. Keep in mind that allow-est-drop-inv-6 already includes a rule for ICMP.

Set Up Zones

Now that we have our rulesets, we need to tell the router about our zones, which interfaces belong to each zone, and which rulesets to apply for traffic originating from other zones. This information goes in the zone-policy stanza of the configuration, with one zone stanza for each zone of our network.

Let’s start by creating a local zone.

# edit zone-policy zone local

Each zone has a default action, which must be either drop or reject.

# set default-action drop

Next specify which interface(s) are in this zone. Normally this would be a set interface <iface> command, but the local zone is a bit different:

# set local-zone

Now we must create from <zone> stanzas to specify which rulesets to apply for traffic from the specified zone to the local zone.

# set from WAN firewall name allow-est-drop-inv
# set from WAN firewall ipv6-name allow-est-drop-inv-6
# set from LAN firewall name lan-local
# set from LAN firewall ipv6-name lan-local-6
# top

Repeat this procedure for the LAN and WAN zones.

Delete Existing WAN Rules

If you’ve been following along you will already have some ACL rules applied to the WAN interface. It’s time to delete those.

# delete interfaces ethernet eth0 firewall
# delete firewall name WAN_IN
# delete firewall name WAN_LOCAL

Apply Changes

Now it’s time to cross your fingers and commit the load of changes we just made. If you’ve made any mistakes the CLI will let you know, and you can correct them and commit again. Don’t forget to save your changes and back them up once everything is working!

Conclusion

Setting up a zone-based firewall on the EdgeRouter is a bit of work, but for me the conceptual simplicity and inherent protection against mistakes make it worthwhile.

In part 3 we’ll talk about setting up VLANs.

Ubiquiti EdgeRouter Lite Setup Part 1: The Basics

2016-03-01T00:00:00+00:00

A few months back I picked up an Ubiquiti EdgeRouter Lite as I started the process of upgrading some of the aging network equipment in my home. So far I’m finding this to be a very substantial upgrade to the typical consumer-grade home networking equipment at a reasonable price. Getting this device configured was a bit of work though, so I’m documenting what a learned here - mostly for my reference, but also in case it proves useful to anyone else.

Please note that for the most part I’m writing this from memory, so there may be mistakes. Since my ERL is currently in use I haven’t been able to validate the configuration steps I provide. If you see mistakes, have problems with any of the steps, or have suggestions for better ways to do things please let me know.

For reference I’ll maintain a collection of links to all my posts about EdgeRouter Lite configuration here, updating it as new posts are added.

About the EdgeRouter Lite

If all you’re familiar with is the standard consumer home networking equipment, it may take a bit of reorienting to understand the role of the ERL. In consumer parlance a router is typically a combination of a router (connects networks together), a switch (connects machines within a network), and a wireless access point (allows wireless clients to connect to the network). The ERL serves only the router function, but it does this with better performance, more flexibility, and (hopefully) better reliability than consumer equipment. It also has a decent CLI, which will be used for almost all the configuration examples in these posts.

Network Configuration

The typical home network consists of just a single network. I work from home though, and I keep my office network separated from our home network to protect my work assets from any potential compromise of my home network. Previously this was done by attaching a second NAT router with firewall behind the router that connected my home from the internet. With the ERL (in combination with a managed switch) I can instead use VLANs to separate my networks for something that looks more like this:

In these posts we’ll gradually work towards setting up the EdgeRouter Lite for this setup.

Initial ERL Setup via the Web UI

Consult the EdgeRouter Lite User Guide for information on accessing the EdgeOS configuration interface for the first time. Bascially, the steps are: connect a machine to the eth0 port on the ERL, manually configure your machine to have an address in the 192.168.1.x subnet, then point your web browser at 192.168.1.1. This will bring up the configuration interface in your browser.

While I prefer the CLI for most of my configuration, the ERL’s web interface contains a handful of wizards for common setups. If you wish to use one of the wizards it is important that this be the first configuration step you perform, as any change to the configuration at all seems to make the ERL insist that you reset to the default configuration before using the wizard.

Once this is done and the ERL reboots, it is imperative that your next step is to change the default password, or better yet add a new user and delete the default user altogether.

Using the CLI

You can access the CLI either within the web UI or over ssh (my preferred method). The OS on the ERL is called EdgeOS and is based on Vyatta, so if you’re familiar with Vyatta the EdgeOS CLI will be familiar. You’ll probably want to consult the EdgeOS User Guide to get familiar with the CLI (refer to Appendix A), but I’ll mention a few of the basics here.

Once logged into the CLI you’re presented with a shell in a Debian-based environment. The first thing to know is that at any time typing ? will bring up context-sensitive help about valid commands and syntax. Typing ? a second time will show more detailed help. The shell also includes context-sensitive tab completion.

There is a show command which can be used to display information about the system. For example, show interfaces displays information about the network interfaces in the system.

To make changes to the configuration you must enter configuration mode by entering the configure command. Configuration mode has show and set commands for displaying and modifying configuration variables, respectively, along with an assortment of other commands.

The configuration itself is hierarchical, with sections which may contain settings or subsections. For example there is a interfaces section which holds the configurations for network interfaces and a firewall section which contains the firewall rules.

Changes made while in configuration mode are staged until they are committed with the commit command, at which point they go into effect, or they can be discarded using the discard command. To save the changes to the default configuration use the save command, and the exit command will return to operational mode. The default configuration is stored in a plain text file at /config/config.boot.

Setting Up WAN+LAN Using the CLI

My setup uses eth0 to connect to the internet and eth2 for my LANs. We’ll start with a basic setup to provide NAT and a basic firewall on the WAN interface and a single network on the LAN interface.

First, let’s set up the firewall to only allow established connections into the network. We’ll go into more details about firewall setup in the next post, but for now note thatt we actually create two sets of rules. One is named WAN_IN and applies to packets coming in the WAN interface destined for other interfaces, and the other is named WAN_LOCAL and applies to packets coming in the WAN interface destined for the router itself.

$ configure
# set firewall all-ping enable
# set firewall broadcast-ping disable
# set firewall ipv6-receive-redirects disable
# set firewall ipv6-src-route disable
# set firewall ip-src-route disable
# set firewall log-martians enable
# set firewall receive-redirects disable
# set firewall send-redirects enable
# set firewall source-validation disable
# set firewall syn-cookies enable
# set firewall name WAN_IN default-action drop
# set firewall name WAN_IN enable-default-log
# set firewall name WAN_IN rule 1 action accept
# set firewall name WAN_IN rule 1 description "Allow established connections"
# set firewall name WAN_IN rule 1 state established enable
# set firewall name WAN_IN rule 1 state related enable
# set firewall name WAN_IN rule 2 action drop
# set firewall name WAN_IN rule 2 log enable
# set firewall name WAN_IN rule 2 description "Drop invalid state"
# set firewall name WAN_IN rule 2 state invalid enable
# set firewall name WAN_LOCAL default-action drop
# set firewall name WAN_LOCAL enable-default-log
# set firewall name WAN_LOCAL rule 1 action accept
# set firewall name WAN_LOCAL rule 1 description "Allow established connections"
# set firewall name WAN_LOCAL rule 1 state established enable
# set firewall name WAN_LOCAL rule 1 state related enable
# set firewall name WAN_LOCAL rule 2 action drop
# set firewall name WAN_LOCAL rule 2 log enable
# set firewall name WAN_LOCAL rule 2 description "Drop invalid state"
# set firewall name WAN_LOCAL rule 2 state invalid enable

Next, set up eth0 as the WAN interface and set up NAT.

# set interfaces ethernet eth0 description WAN
# set interfaces ethernet eth0 address dhcp
# set interfaces ethernet eth0 firewall in name WAN_IN
# set interfaces ethernet eth0 firewall local name WAN_LOCAL
# set service nat rule 5010 description "Masquerade for WAN"
# set service nat rule 5010 outbound-interface eth0
# set service nat rule 5010 type masquerade

Finally, set up eth2 as the LAN interface with DHCP, and listen for DNS queries for clients on this network.

# set interfaces ethernet eth2 description LAN
# set interfaces ethernet eth2 address 192.168.1.1/24
# set service dhcp-server disabled false
# set service dhcp-server shared-network-name LAN authoritative enable
# set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1
# set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 dns-server 192.168.1.1
# set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 lease 86400
# set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 start 192.168.1.150 stop 192.168.1.254
# set service dns forwarding listen-on eth2

Now commit and save the changes.

# commit
# save
# exit

Backing Up and Restoring Your Configuration

Once you have something that’s working it’s important to back up the configuration file. It’s possible to save the configuration to another host using the save command, but this is one case where I prefer to use the web UI. Once logged in, click on the System button on the bottom of the screen, find the Back Up Config section, and click the Download button. The configuration can be restored from a backup here as well.

The EdgeRouter supports revisioning of the configuration, but I prefer to just store revisions in my own git repository. More information about managing the config file can be found here.

It’s more convenient and more secure to log into ssh using public key authentication than with password authentication. I’ll assume you’re already familiar with key-based authentication, if not a quick search should turn up plenty of resources.

The first step is to copy your ssh public key to the ERL. For example, using scp on your local machine:

$ scp ~/.ssh/id_rsa.pub <ip-of-erl>:/tmp

After this you need to associate the public key with your user on the ERL. Log into the ERL and run these commands:

$ configure  
# loadkey <user> /tmp/id_rsa.pub  
# commit  
# save  
# exit

In theory this should be all that is needed, but I had to do one additional manual step. For some reason my home directory and some of its contents were owned by uid 1000, which was not the id of my user. Key-based ssh login would not work until I fixed this. On the ERL run:

$ sudo chown -R <user> /home/<user>

Now you should be able to log out and then log back in using your ssh key.

That’s it for part 1. In part 2 we’ll go into detail about setting up the firewall.

Container Mounts in Ubuntu 16.04

2016-02-22T21:26:00+00:00

Something I’ve been working on for a while now is mounting select filesystems from within unprivileged (i.e. user namespace) containers. Though I’m still working on getting this into upstream Linux, support for mounting fuse and ext4 was recently merged as an opt-in feature in the xenial kernel. The instructions below will help you get started if you’d like to give this a try.

But first a word of warning: this feature is experimental. As far as I know it should be stable, but there are known security concerns, specifically with mounting ext2/3/4 volumes¹. It should only be enabled in trusted environments where potentially malicious users do not have shell access to your system.

Requirements

In order to use this feature, you will need a 4.4.0-6.21 or later kernel in Ubuntu xenial. To follow these instructions you will also need to have lxd installed (help for this can be found here).

Setup

The first thing you need to do is flip the module parameters to enable user namespace mounts for fuse and/or ext4.

$ echo Y | sudo tee /sys/module/fuse/parameters/userns_mounts
$ echo Y | sudo tee /sys/module/ext4/parameters/userns_mounts

A lxd container running under the default profile will not have the device nodes needed for mounting (/dev/fuse for fuse and some block device for ext4, e.g. /dev/loop0) and will not be permitted to mount by AppArmor. We need to create a lxd profile which will include the device nodes and run the container without AppArmor confinement. This will be used on top of the lxd default profile.

$ lxc profile create nsmount
$ lxc profile set nsmount raw.lxc lxc.aa_profile=unconfined
$ lxc profile device add nsmount fuse unix-char path=/dev/fuse
$ lxc profile device add nsmount loop0 unix-block path=/dev/loop0

Now create a new container using this profile.

$ lxc launch ubuntu u1 -p default -p nsmount

Testing it out

Let’s try fuse first. Launch a shell in your new container:

$ lxc exec u1 -- /bin/bash

Inside the container we can create an ext2 filesystem and mount it using fuseext2, adding the ‘-o force’ option to make the mount read/write.

# apt-get install fuseext2
# dd if=/dev/zero of=ext2.img bs=1M count=8
# mkfs.ext2 ext2.img
# mkdir -p mount
# fuseext2 ext2.img mount -o force

You can now browse and modify the filesystem. To unmount run:

# fusermount -u mount

For ext4 we’ll create the filesystem outside of the container and set this as the backing store for /dev/loop0. If loop0 is already in use you can pick another loop device, in which case you’ll also need to modify the nsmout lxd profile to make that device available in the container.

Back in the host run:

$ dd if=/dev/zero of=ext4.img bs=1M count=8
$ mkfs.ext4 ext4.img
$ sudo losetup /dev/loop0 ext4.img

Then back in the container run:

# mkdir -p mount
# mount /dev/loop0 mount

This filesystem can be unmounted in the usual way.

The known security concern is that a malicious user could provide a crafted filesystem to exploit bugs in the in-kernel filesystem parsing code, or the user could change the backing store at runtime. Either of these could lead to kernel crashes or worse. ↩

Introduction to Creating DKMS Packages for Ubuntu, Part 2

2012-03-16T14:02:00+00:00

The DKMS framework makes it easy to create and distribute an out-of-tree kernel module, as demonstrated in part 1. However, the process is rather manual (read: error prone) for packages that will be updated regularly. This post is going to look at a way to set up the debian packaging components to make updating easier. A basic familiarity with debian packaging is assumed.

As an example, we’ll use an updated version of the apple-gmux-dkms source tree from part 1, which can be donwloaded here. This time it’s not necessary to extract it to /usr/src; just extract it to wherever you like in your home directory.

The layout of the files has changed a little bit. The source file and makefile are still in the root of the tree, but dkms.conf has been moved into the debian directory and renamed to apple-gmux-dkms.dkms.in. We’ll talk more about this file later. Most of the remaining files are the typical debian packaging boilerplate; examining these files is left as an exercise for the reader. The one file we will take a closer look at is debian/rules.

The first item of note in the rules file is that it grabs the version number for the package from the changelog with the following.

version := $(shell dpkg-parsechangelog | grep '^Version:' | cut -d' ' -f2 | cut -d- -f1)

This eliminates the error-prone process of making sure the version gets updated throughout the package by making the changelog the canonical location for the version number. Towards that end, the rules file also has a rule to auto-generate the DKMS configuration file, debian/apple-gmux-dkms.dkms, from apple-gmux-dkms.dkms.in. This file is identical to the dkms.conf file used in part 1, except that the version number has been replaced by the string @VERSION@. A sed command is used to generate the config file with @VERSION@ replaced by the actual version number.

debian/apple-gmux-dkms.dkms: debian/apple-gmux-dkms.dkms.in  
    sed s/@VERSION@/$(version)/g $< > $@

The other item worth noting is that there’s a DKMS debhelper, dh_dkms, which makes setting up the rules file a breeze when used along with the dh helper (for more information about the dh helper consult the man page). We just need a rule to let dh do its thing:

%:  
    dh $@

Then we need to override a few of the debhelper commands to install files for the DKMS package and to invoke dh_dkms. We also need to clean up the auto-generated DKMS configuration file, and since we’re not actually building anything to generate the package we override the build command to do nothing. This leaves us with the following override rules.

override_dh_clean:
        dh_clean debian/apple-gmux-dkms.dkms

override_dh_auto_build:
        :

override_dh_auto_install: debian/apple-gmux-dkms.dkms
        dh_install apple-gmux.c Makefile /usr/src/apple-gmux-$(version)/
        dh_dkms

override_dh_auto_install_indep: debian/apple-gmux-dkms.dkms

That’s it! Now you can build the binary and source packages with the usual debian packaging commands. When it comes time to update the package, you only need to update the version number in the changelog to get it updated throughout the package.

Seth Forshee’s Blog

EdgeRouter: Accept OpenVPN Connections on Multiple Ports

Which Ports?

Setting Up DNAT

Limitations

Fixing 256-color Support with tmux in terminator

Ubiquiti EdgeRouter Lite Setup Part 6: Odds and Ends

Dynamic DNS

Static DHCP Mappings

Changing the Host Name

Google Fiber

Staying Up to Date

Conclusion

Ubiquiti EdgeRouter Lite Setup Part 5: OpenVPN Setup

Generating Certificates

OpenVPN Server Setup

Firewall Setup

Final Steps and Testing

Hardening

Conclusion

Ubiquiti EdgeRouter Lite Setup Part 4: IPv6 Setup

DHCPv6 and Prefix Delegation

WAN Setup

LAN Setup

Potential Problems

Conclusion

Ubiquiti EdgeRouter Lite Setup Part 3: VLAN Setup

Adding VLANs

VLAN Configuration

Firewall Rules

Deleting the Old Configuration

Guest/IoT VLAN

Conclusion

Ubiquiti EdgeRouter Lite Setup Part 2: Firewall Setup

ACL vs. Zone Based Firewall

Setting Up a Zone Based Firewall

Define Zones and Allowed Connections

Create Firewall Rulesets

Set Up Zones

Delete Existing WAN Rules

Apply Changes

Conclusion

Ubiquiti EdgeRouter Lite Setup Part 1: The Basics

About the EdgeRouter Lite

Network Configuration

Initial ERL Setup via the Web UI

Using the CLI

Setting Up WAN+LAN Using the CLI

Backing Up and Restoring Your Configuration

Key-Based SSH Login

Container Mounts in Ubuntu 16.04

Requirements

Setup

Testing it out

Introduction to Creating DKMS Packages for Ubuntu, Part 2