As a router I use an EdgeRouter Lite managed with EdgeOS. EdgeOS is very flexible, but does require work to configure, which this post is about.
My setup is with a LAN (
eth1), a WAN (
eth0) and a DMZ (
eth2) such that
- LAN can access DMZ and WAN.
- DMZ can access WAN, but not LAN.
- WAN has limited access to DMZ.
My setup is compiled from a number of sources. Specific sources are found in the relevant part, the general are:
My full configuration file is found here.
How to configure
The changes can be entered by changing to configuration mode with
configure and then typing them individually.
When finished with the changes remember to
For the initial setups I think this is a good way, as it is easy to catch errors.
In configuration mode word completion is activated and with a double
?, the commands are explained.
Unfortunately, word completion is not working in the default shell.
For the longer configurations like firewall policies, I prefer to make a configuration file and load this with the command
To have a valid starting point, I first save the current configuration in
~/config.new (alternatively copying
In order to see how how the current configuration can be entered, use
show configuration commands.
To delete a single setting like the setup for the
eth0 port, use
delete interfaces ethernet eth0.
If things mess up completely, the default configuration is located at
How not to configure
At first, instead of loading a new config file, I simply replaced
This was not a good idea!
Afterwards I could not access the router through the ethernet ports – even after a factory reset.
Connection could be established through the console port, but the router did not make it and eventually I had to get a new one.
Connection through the console port
To gain access through the console port a special RJ45-to-DB9 (and possibly an adaptor cable) is needed. On my Mac I used the program CoolTerm to establish the connection.
For future reference, it may be possible to recover a broken EdgeOS using this EdgeOS rescue kit.
I had two problems:
- I could not figure out how to make the file transfer with the TFTP (Trivial FTP) protocol from my computer to the router.
- My lack of luck in restoring the default configuration lead others to suggest that the router’s flash drive was broken.
On a fresh system I change the host name to
DJ-edge and add the user
configure set system host-name DJ-edge set system login user admin authentication plaintext-password <password> commit save exit
When these commands are executed, logout from the
ubnt account and login as the new user
Next I delete the default user
ubnt, enable login over SSH with RSA keys and disable login with password (remember to transfer the public key to the router first or load the key over scp).
configure delete system login user ubnt loadkey admin /path/to/id_rsa.pub set service ssh disable-password-authentication commit save exit
Remember to test login with the RSA key before disabling login with password!
I ran into an odd problem after adding
The home dir (
/home/admin) belonged to the mysterious user “1000” and
/home/admin/.ssh was not world readable, thus the RSA key cannot be read.
I solved this by changing to
root and running
sudo chown -R admin .
The possible timezones can be found in
/usr/share/zoneinfo/ and set using
set system time-zone Europe/Copenhagen
Bash is the default shell and to make navigation easier I add a couple of lines to
alias ll='ls -l' alias la='ll -a' alias ..='cd ..' HISTFILESIZE=100
The last line is a replacement for
At some point new versions of EdgeOS become available at Ubiquiti’s webpage: Log in to the web GUI, go to ‘System’ (currently in the bottom left corner) and use the link under ‘Upgrade System Image’.
Ubiquiti has a fine guide on how to upgrade using the command line:
- Transfer the downloaded
upgrade.tarto the router with e.g.
- Log in to the router and run
add system image upgrade.tar
- To see if the upgrade has been loaded properly run
show system image
- You are told to reboot to use the new image.
The routing settings are the interfaces for the ports, the local DHCP and DNS servers and the firewall.
edit interfaces ethernet eth0 set description "LAN" set address 192.168.1.1/24 set duplex auto set speed auto top
edit interfaces ethernet eth1 set description "WAN" set address dhcp set duplex auto set speed auto top
edit interfaces ethernet eth2 set description "DMZ" set address 192.168.0.1/24 set duplex auto set speed auto top
DHCP and DNS
For the LAN and DMZ networks the router works as the DHCP and DNS server.
Global DHCP options:
edit service dhcp-server set disabled false set dynamic-dns-update enable true top
The LAN subnet leases the addresses 192.168.1.100-254:
edit service dhcp-server shared-network-name LAN_DHCP set authoritative disable edit subnet 192.168.1.1/24 set default-router 192.168.1.1 set dns-server 192.168.1.1 set lease 86400 set start 192.168.1.100 stop 192.168.1.254 top
The DMZ subnet leases the addresses 192.168.0.100-254:
edit service dhcp-server shared-network-name LAN_DHCP set authoritative disable edit subnet 192.168.0.1/24 set default-router 192.168.0.1 set dns-server 192.168.0.1 set lease 86400 set start 192.168.0.100 stop 192.168.0.254 top
For LAN and DMZ the router is defined as the primary DNS server. To support this, DNS forwarding should be enabled:
edit service dns forwarding set cache-size 200 set listen-on eth0 set listen-on eth2 top
This choice is also reflected by the firewall rules, as both LAN and DMZ should have a minimum of access to the router (
By default the web GUI is available from all ports.
To restrict access to only the LAN port set the listen address to match the one on
set service gui https-port 443 set service gui listen-address 192.168.1.1
Network Address Translation
To allow local machines to access the internet a NAT masquerade is needed to translate IP addresses between the LAN/DMZ and WAN:
edit service nat rule 5000 set description "WAN masquerade" set log disable set outbound-interface eth1 set protocol all set type masquerade top
There are two ways of specifying firewalls:
ACL and zones.
I like the flexibility of zones and use these.
When using zones, every connection defaults to a drop/reject and hence a firewall rule must be specified for each combination of interfaces where a connection is desired.
It may be a good idea to specify a firewall even if a connection is never used, as it allows logging.
The zones are
LOCAL (the router itself).
The very first policy to make is one that allows connections from LAN to LOCAL; without such a rule, further configuration is prohibited.
For some reason, when adding a LAN to LOCAL rule, SSH access takes forever.
A solution to the problem is to disable DNS lookup for OpenSSH:
In the file
/etc/ssh/sshd_config change the line
UseDNS yes to
UseDNS no and restart the SSH server with
sudo /etc/init.d/ssh restart for the changes to take effect.
When the device boots
/etc/ssh/sshd_config is overwritten with
/opt/vyatta/etc/ssh/sshd_config, so edit the last file for the change to be permanent.
As suggested elsewhere I use the following naming conventions for the firewall rules:
Rule 1 - State Established, Related Rule 2 - State Invalid Rule 100 - ICMP Rule 200 - Web Rule 300 - FTP Rule 400 - NTP Rule 500 - SMTP Rule 600 - DNS Rule 700 - DHCP Rule 800 - SSH Rule 900 - IMAPS default-action drop enable-default-log
There is one exception for me:
On the ‘allow all’ rules I include the
new state in rule 1.
To setup access from WAN to DMZ both the public IP address and a port should be specified.
The router applies NAT rules before firewall rules, so a NAT rule must be specified that translates
edit service nat rule 200 set description 'Web access to DMZ' set destination port 314 set inbound-interface eth+ set inside-address address 192.168.0.11 set inside-address port 443 set log enable set protocol tcp set type destination top
inbound-interface eth+ means that the translation applies to all ports.
My router complains that the
+ option is not available, but the setup works as expected.
The firewall rule
WAN-to-DMZ allows access if the port mathces the one from
In order to access the DMZ using
public:port from a unit on the LAN a NAT Hairpin masquerade rule is needed.
Without such a rule the host on the DMZ can only be accessed from the LAN through its local IP.
edit service nat rule 5011 set description 'Masquerade hairpin eth0' set destination address 192.168.1.1/24 set log disable set outbound-interface eth0 set protocol tcp set source address 192.168.1.1/24 set type masquerade top
I also have a rule allowing SSH access to the DMZ and as an attempt to reduce the number of incoming connections, I follow the advice from this blog to limit the number of new SSH connections to DMZ.
The current version of EdgeOS does have a
port-forward option to reduce the hazzle – but I do not like its black box magic.
Some units on my network (like my TV) benefits from having a static IP. This can assigned by matching the unit’s MAC address:
set service dhcp-server shared-network-name LAN_DHCP subnet 192.168.1.1/24 static-mapping TV ip-address 192.168.1.20 set service dhcp-server shared-network-name LAN_DHCP subnet 192.168.1.1/24 static-mapping TV mac-address xxxxxx:xx
EdgeOS is based on Debian and thus a wealth of packages are available. Add repositories:
edit system package repository wheezy set components 'main contrib non-free' set distribution wheezy set url http://http.us.debian.org/debian top edit system package repository wheezy-security set components main set distribution wheezy/updates set url http://security.debian.org top
Update the repositories:
sudo apt-get update
Now programs can be installed as on a usual Debian distribution, e.g., Git:
sudo apt-get install git