Configuring the Edgerouter Lite (ERL)

Preface

The webinterface of the Edgerouter is quite cute, but as of EdgeRouter Lite v1.10.5 it is not capable to configure IPv6. So I describe all configuration steps as a sequence of CLI commands.

The Edgerouter has a powerful command line interface. Unfortunately the configuration of this device gets very quickly a confusing extent and the presentation within the CLI isn't very helpful.

To actually configure the Edgerouter you have basically two options:

1. use the CLI
2. edit the configuration file directly

The first approach is well documented so I skip it here. The second approach is to open the configuration file '/config/config.boot' with your favorite editor (which should always be 'vi' :-) and load it via the CLI afterwards. This allows you to jump around and edit the configuration at the same time. The interesting CLI commands for this context are:

• load
• save
• merge

Another useful capability of the CLI is to show the configuration as a sequence of 'set' commands which you can copy & paste. To see the whole configuration you can use

from the command line (not in configure mode). If you only want to see a specific section of the configuration in this way use this:

Setting up the interfaces

On the Edgerouter I utilise the interfaces in the following way:

eth0: WAN interface
eth1: WLAN interface
eth2: LAN interface

Let's start with the internet uplink eth0. The basic settings should be self-evident:

Thats the IPv4 part. The IPv6 configuration should happen automatically.

Now for the prefix delegation.
First I request a subnet on our WAN interface:

The Fritzbox documentation mentions that the device only allows one /62 per delegation at maximum. That's perfect for me as it is exactly the size I want. That means we now have four /64 network ranges. The next step is to tell the Edgerouter what it should do with them. I start with my LAN interface:

prefix-id ':0' pertains to the first subnet of our delegation. The other two lines tell the Edgerouter to take the first IP address (::1) for itself and offer slaac (Stateless Address Auto Configuration) to clients. The netmask (/64) is implicit. I repeat these lines for my WLANs:

The next line is not important, but it does not hurt either:

Now let's configure the WLAN interface.
Step 1: configure the transfer network to the AP:

Step 2: add the different VLANs for the WLANs:

Step 3: activate router advertisements for the IPv6 networks:

The configuration of the wired LAN interface is accordingly and straight forward:

Finally I enable DNS service for our LAN segments:

Configuring DHCP

Setting up DHCP is pretty simple. The only thing is: it does not work for IPv6! At least when using slaac. DHCPv6 needs static address ranges and since we have none I can use none. That means I can only configure DHCP for IPv4, which is pretty much straight forward and simple.

In advance I should consider how I split the networks into sensible parts. My thoughts on this is that I have three types of clients and therefor three subnets:

1) Trusted well known clients.

This includes my desktop, my printer etc.
They get an IP in the range .1 - .63, i.e. x.x.x.0/26, statically assigned via DHCP.

2) Not fully trusted well known clients.

These are clients which I know, but do not fully trust, e.g. my smart phone.
They get an IP in the range .65 - .127, i.e. x.x.x.64/26, statically assigned via DHCP.

3) Totally untrusted clients.

For example my Firestick or Guests.
They get an IP in the range .129 - .154, i.e. x.x.x.128/25, dynamically assigned via DHCP.

So lets get our hands on. I start with setting some global options:

Next I configure the transfer network to the AP, assigning a static IP to the AP:

The other networks are configured accordingly and only differ in the list of known clients. This should be very self-explanatory and I skip the details.

Configuring The Firewall

To avoid this you have three choices:

1. Configure the device while eth0 (the internet uplink) is not connected
2. Configure the firewall ruleset first
3. Ignore the danger

Some general considerations

There are different types of firewalls:

"Flat"

You define one ruleset for all traffic, regardless of interfaces and zones. This type is found on solaris- and BSD-systems, among others.

Interface-based

Here you can define one firewall ruleset per interface and direction, i.e. "LAN_IN" and "LAN_OUT" etc. You'll find this e.g. on cisco systems (although cisco meanwhile also supports the zone-based model).

Zone-based

Here you assign interfaces to zones, eg. "LAN" and "WLAN" reflecting the purpose of the interfaces. The firewall ruleset is held in inter-zone policies, so you have one policy for "LAN to WLAN", one for "LAN to WAN" etc. This way you configure one ruleset for each "from interface X to interface Y" combination. This type is implemented for instance by Juniper firewalls.

Which type of firewall to use is not a question of security, they all protect your network, it's a matter of taste and, above all, usability. And 'usability' is not a universal attribute you can assign to any type in general. It most often depends on preset conditions. Like in my case. For the IPv4 part of my network I could use the flat model and put all rules into one set. A simple "from source X to destination Y using port Z is allowed" per permission is very clear and I don't have to visit several rulesets in order to know what is actually allowed. That makes the policy well arranged and clear.

On the other hand the flat-model can become very cumbersome. In commercial environments it isn't unlikely that the policy holds several thousands rules. Although this normally isn't an issue in home or small office networks, there are other reasons to split the ruleset into handy pieces. Defining a policy per interface can make the ruleset very compact because it does'nt need to take care about networks which are not involved. On the downside you have to consider several policies when you want to allow a certain communication. For that reason most admins define only one policy per interface-direction (e.g. "LAN_IN", "WAN_IN" etc.) and disregard the other direction completely.

Zone-based firewalls force you to define a ruleset for each inter-zone relation. If you want to allow traffic from source X to destination Y, your first task is to find out which zones are involved. And this can be difficult if you have many of them. Additionally there are two policies involved, e.g. "LAN_TO_WAN" and "WAN_TO_LAN" for allowing traffic from the inside to the internet.

As you can see all three types have their (dis-) advantages. Luckily for me my network is not that complicated. And since the Edgerouter supports all three types (well the flat model only fair to middling), I can choose freely which type I use.

Really?

Sure!

...

Wait.

For the IPv4 part of my network this is true. I can always associate a source address with a permission because I, myself, defined the ranges involved. But for the IPv6 part I don't know which prefixes are in use. They change every day (depending on your provider) and you can not define rules without known prefixes. And although the underlying iptables supports rules like "allow port X from interface Y to interface Z" the EdgeOS is limited and does not support them (in the flat model).

So I have two options left: zone-based and interface-based

If we use interface-based rules, we only see one interface and one direction. Either in (the traffic originates from this interface) or out (the traffic is destined to this interface), but never both interfaces (the originating and the destination interface). For that reason we can not use interface-based rules.

So there is only one option left: zone-based policies.

Planning my rulesets

Now that I have choosen my preferred type of firewall, I have to cogitate what policies I need. As said before, I do not want to allow LAN to LAN traffic via IPv6. And keep in mind that although you can define a ruleset for every inter-zone relation you are not forced to do so. So in summary that should be simple and I need three rulesets for IPv6:

lan_lan_v6

for LAN to LAN communication, including local access to the Edgerouter

lan_wan_v6

for LAN to WAN communication

wan_lan_v6

for WAN to LAN communication, including local access to the Edgerouter

For IPv4 I need one more. Since there can be no access from the internet to the internal LAN or the Edgrouter we essentially need no ruleset for this communication. But later on we define a default behavior (deny all) for WAN to LAN traffic, and that would block replys to queries originated from inside, too. So we need four rulesets:

lan_lan_v4

inter LAN traffic

lan_local_v4

local access to the Edgerouter

lan_wan_v4

WAN traffic

wan_lan_v4

replys to WAN traffic

That sums up to remarkable 7 (!) rulesets for such a neat little network.

For my rules I use some default settings:

set default-action drop

define the default action, drop anything which is not explicitly allowed

Set enable-default-log

Log everything which is handled by the default rule

Defining the rulesets

Let's start with the rules for IPv6:

We begin with the rules for LAN to LAN communication.

set firewall ipv6-name lan_lan_v6 default-action drop set firewall ipv6-name lan_lan_v6 enable-default-log set firewall ipv6-name lan_lan_v6 rule 1 action accept set firewall ipv6-name lan_lan_v6 rule 1 description 'Allow established/related sessions' set firewall ipv6-name lan_lan_v6 rule 1 state established enable set firewall ipv6-name lan_lan_v6 rule 1 state related enable set firewall ipv6-name lan_lan_v6 rule 2 action drop set firewall ipv6-name lan_lan_v6 rule 2 description 'drop invalid packets' set firewall ipv6-name lan_lan_v6 rule 2 protocol all set firewall ipv6-name lan_lan_v6 rule 2 state invalid enable

This sets the default policy to drop, and all dropped packets are logged. As said above, this is exactly what I want. So we are finished here.

Almost...

We want to provide stateless address auto-configuration (slaac) to our internal clients. So there must be some kind of traffic. In IPv6 most automagic things are based on special addresses: link-local and multicast addresses. To explain all this would go far beyond the scope of this article. Just notice that I decided to allow such traffic with the following three rules:

That's the part for LAN to LAN. So let's move on to LAN to WAN. In this case it is really easy and short. We allow everything:

That's all. Now for the WAN to LAN traffic:

Rule 1 sets the ruleset into stateful mode. All traffic which is already allowed or belongs to an already allowed connection is still allowed. This allows replys to queries originating from our LAN. Rule 2 lets the firewall inspect and drop packets with invalid header information. I add some additional rules:

I allow ICMP, link local and traffic originating from my servers. That's all for the IPv6 part.

For IPv4 I start with LAN to WAN traffic. Pretty short, just as the IPv6 equivalent:

WAN to LAN is similar to the IPv6 version:

For IPv4 I want to allow print service to parts of my internal networks. Printing may involve several TCP ports. So I group them together:

Now I can use this group for my ruleset. This should be very self-explanatory:

Finally we allow certain traffic to the Edgerouter. For this I define an additional group for trusted sources:

set firewall group network-group trusted network 172.17.15.0/26 set firewall group network-group trusted network 172.17.16.0/26 set firewall group network-group trusted network 172.17.17.0/26

Which I can now use for my ruleset:

Define zones and apply the rulesets

Now we have all our rules together. Our next job is to build up the zones and assign the corresponding rulesets. The scheme is always the same. You denominate the zone, set a default policy and assign interface(s) to the zone:

So we now have a zone called 'guests' assigned to eth1.102. Next we assign one ruleset per source zone. We need to assign one ruleset for IPv4 and one for IPv6 (so effectively 2 rulesets per source zone):

The other zones are accordingly:

As you can see you can assign more than one interface to a zone (see "trusted").

Configuring dyndns

When you have configured your Edgerouter for your nice network you probably want to use a dynamic DNS service. I found it quite difficult to setup dyndns with IPv6. And the documentation of the ERL was not of much help. My next attempt was to look how dyndns is implemented on the ERL and I found it uses ddclient. A version check showed ddclient version 3.8.3

Reading the documentation for this ddclient version and some try and error attempts drove me crazy. Looking and comparing the source of ddclient proved that Ubiquiti Networks is using a modified version of ddclient v3.8.3, including some patches for IPv6. But how can we use and configure it correctly?

After some more try and error I came up with this working configuration:

To be able to retrieve my ip addresses I have set up some URLs. Feel free to use them. They provide nothing but the pure IP:
http://myip.updatedns.de/ gives the IP you are using. Should always be your IPv6 address if your host has a usable IPv6 address.
http://ip.updatedns.de/ gives always your IPv4 address.
http://ipv6.updatedns.de/ gives always your IPv6 address.

The Edgerouter is now readily configured and I can continue with configuring the Unfiy Access Point.