Pre-requisite: Please go through demo setup page
OpenWrt / LEDE
- Highly extensible Linux distribution for embedded devices (typically wireless routers)
- Ported to hundreds of routers, it is one of the most popular software distributions for home routers
- Very customisable, it includes both the default command line interface as well as a web GUI called LuCI.
- OpenWrt is included in the demo images to allow easily customized routing and network functionality.
- Extensive documentation and community support (https://wiki.openwrt.org/about/start)
- LEDE is an actively maintained fork of OpenWRT. See http://lede-project.org/
- With Project Golden Gate, OpenWrt is supplied as an add-on feature running in a separate virtual machine
- This allows users to configure the Raspberry Pi3 as a router, or to leave it with the default settings if additional router functionality is not needed (e.g. in case you already have a router)
The system is configured with up to three physical interfaces:
- eth0 (wan): the untrusted external network interface
- eth1 (lan): the trusted internal wired interface (optional)
- wlan0 (wlan): the trusted internal wireless interface
The Application VM sees these three interfaces, and has hardware access to them, but the non-bypassable network filter in the Application VM filters network traffic via the LEDE VM. To do this, each physical interface appears as two separate logical interfaces in the LEDE VM:
- eth0_ext (wan), eth0_int (wan_int)
- eth1_ext (lan), eth1_int (lan_int)
- wlan0_ext (wlan), wlan0_int (wlan_int)
Note that LEDE does not know that wlan0_ext is a wireless interface. Wireless hotspot configuration and authentication is managed by the Application VM, but LEDE runs a DHCP server to allocate addresses to wireless clients.
In addition, there are two virtual ethernet interfaces to the DIT (VPN) VM:
- vpn-ext (vpn_external): the external interface used for incoming VPN connections
- vpn-int (vpn_internal): the internal interface used for traffic to/from VPN clients.
These two interfaces are purely virtual and connect to the DIT and LEDE VMs only.
Filter Operation Overview
When a network packet is received on one of the physical external interfaces, e.g. eth0, it is intercepted by the non-bypassable network filter in the Application VM and forwarded to the corresponding external interface, e.g. eth0_ext, in the LEDE VM. The packet can then be inspected, modified or filtered using iptables rules. If the packet is to be forwarded to the Application VM, it is sent to the corresponding internal interface, e.g. eth0_int. The Application VM then sees this packet appear on its eth0 interface with no knowledge that it has been filtered via LEDE.
When the Application VM transmits a packet to a physical interface, the non-bypassable network filter intercepts the packet and forwards it to the corresponding internal interface, e.g. eth0_int. As with incoming packets, LEDE decides what to do with this packet, and if it is to be transmitted on the actual physical interface, it will be forward to eth0_ext, and then via the network filter back to the Application VM for transmission via the physical interface.
LEDE is configured to forward most incoming network traffic on the trusted interfaces (wlan0 and eth1) to the Application VM, but it intercepts the following packets (port numbers are written as src/dest):
- DHCP (UDP 68/67), DNS (UDP /53) and SSH (TCP /22)are handled by LEDE
- TCP ports /8000 (http) and /8443 (https) are forwarded to LEDE’s web management interface (LuCI).
- IPSec NAT traversal (UDP /500 and UDP /4500) is forwarded to the VPN VM.
On the untrusted interface (eth0), LEDE accepts DHCP replies and forwards IPSec NAT traversal to the VPN VM. All other incoming connections are blocked.
The Application VM uses DHCP for all interfaces. Addresses are allocated by a DHCP server running on the correspoding internal interface in LEDE (eth0_int, wlan0_int and eth1_int).
LEDE is configured to use DHCP on eth0_ext and static addresses on all other interfaces, with DHCP servers running on all interfaces except the two virtual interfaces to the VPN VM:
- eth0_int: 10.34.90.1/30, allocates 10.34.90.2 to the Application VM
- eth1_int: 10.34.90.9/30, allocates 10.34.90.10 to the Application VM
- wlan0_int: 10.34.90.5/30, allocates 10.34.90.6 to the Application VM
- eth1_ext: 10.34.92.1/24, allocates 10.34.92.2 – 10.34.92.254 to clients
- wlan0_ext: 10.34.91.1/24, allocates 10.34.91.2 – 10.34.91.254 to clients
- vpn-int: 10.34.90.133/30
- vpn-ext: 10.34.90.129/30
The VPN VM uses static addresses for its interfaces:
- vpn-int: 10.34.90.134/30
- vpn-ext: 10.34.90.130/30
LEDE is configured to use the domain d4-secure and hostnames within the domain are managed with dynamic DNS by dnsmasq. The trusted interfaces are assigned the names gw-wlan.d4-secure and gw-lan.d4-secure. The hostname gw.d4-secure may also be used, but it is not guaranteed to map to any particular physical interface (it depends upon the order of interface creation).
When the system is booted for the first time, it configures itself with the default network settings. Each VM independently configures its own network parameters, and at least the LEDE and VPN VMs must have the same understanding of the network configuration. The Application VM is largely independent because it uses DHCP for all interfaces, although it does manage the Wi-Fi hotspot authentication via hostapd.
LEDE’s network configuration is stored in /etc/config/network, with firewall rules in /etc/config/firewall and DHCP/DNS settings in /etc/config/dhcp. All of these settings can be modified using the uci command line tool or the LuCI web interface.
LEDE assigns firewall rules to zones, and so each of the eight interfaces has its own firewall zone, and its own set of firewall rules. Almost all of these rules are configured via uci, except for two which cannot be defined using the uci syntax. These are added to /etc/firewall.user when the system is first booted.
NOTE: Due to the number of network interfaces and the relationships between them, the LEDE configuration is rather complex and modification without a detailed understanding of how it works is not recommended. Changing the subnets used requires matching changes in the VPN VM so that StrongSWAN can correctly route traffic from clients (the StrongSWAN configuration supports split tunnelling so only local subnets will be routed via the VPN).
LEDE defaults to having no password for access to its web interface. We recommend that the user sets a password as soon as possible after first booting the system.