OpenWrt VLANs: a primer


Updated: 2018-01-10

Use case

The Belgian ISP Telenet supplies their TV customers with a DVR (called 'Digicorder') along with their own modem/router combination. As long as you do not implement your own network behind their modem/router, all is fine, and your DVR is fully functional ('interactive'). It's not completely clear how Telenet exactly sets up the DVR - their modem being a bit of a black box - but it needs both a LAN and a WAN IP. If you use their modem only as such and install a third-party router behind it to manage your network, the DVR loses its WAN IP, and you cannot order movies on demand anymore, access the EPG, program recordings, etc.

The trick is to configure a VLAN so the DVR gets a direct 'line' to the modem, to get it a WAN IP. Little consumer grade hardware supports this - at least: not out of the box. Popular routers like the Netgear WNDR3700 or the TP-Link TL-WR1043ND, for example, use a Realtek switch that does support VLAN tagging, but neither Netgear or TP-Link provide access to those features in their official firmwares. OpenWrt, however, allows you full VLAN control. The existing LAN, in fact, is a VLAN itself, but since there is only one VLAN present on the device, there is no tagging required, and as such it is invisible to the end user - until you start digging.

VLANs: the basics

To understand what a VLAN actually does, a quick network crash course is in order. Computer networking is based on a model with seven layers, the physical layer being the first. VLANs operate on layer 2, called the 'data link layer' - the same layer as Ethernet, DOCSIS, PPP, Token Ring, ... (some of them no doubt sound familiar). Now, on top of that you pile layer 3, the 'network layer'. Here, you have protocols like IP (IPv4, IPv6), ICMP (colloquially known as ping), and so on. IPv4 and ping are familiar - well, VLANs are just on the layer below.

Having access to VLANs allows you great flexibility. You can reconfigure your switch at will; a regular modern router has five ports, one assigned to the WAN, the four remaining to the LAN. With VLANs, you can assign more ports to the WAN, disable the WAN altogether, create a second LAN, and so on.

A standard VLAN layout may look like this:

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 5t'

VLAN port numbering does not necessarily match physical port numbering on the outside of the devices. The example above is the default VLAN layout on my Netgear WNDR3700, where port 0 is labeled as port 4 on the outside and so on. You can use the swconfig tool to get (and set) the configuration of your switch, but it will not tell you if your ports are labeled differently on the outside. On the WNDR3700, to find on which port the CPU is linked, run this:

# swconfig dev switch0 help|head -1
switch0: rtl8366s(RTL8366S), ports: 6 (cpu @ 5), vlans: 4096

As you can see, the CPU is on port 5. On a TP-Link TL-WR841N v7 it looks like this:

# swconfig dev switch0 help|head -1
switch0: eth0(AR7240/AR9330 built-in switch), ports: 5 (cpu @ 0), vlans: 16

On the TP-Link, the CPU is linked to port 0. If the device page on the OpenWrt wiki does not contain any information on the port mapping, you can check the OpenWrt git tree for the port mapping. Look for target/linux/<architecture>/base-files/etc/board.d/02_network. For the WNDR3700, e.g., that will clearly show the external numbering is inverted compared to the internal one:

wndr3700|\
wndr3700v2|\
wndr3800|\
wndr3800ch)
     ucidef_set_interfaces_lan_wan "eth0.1" "eth1"
     ucidef_add_switch "switch0" \
     "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "5@eth0"

The last line is the one you need. This defines the human-readable port mappings: Port 0 is labeled 4 on the outside, port 1 is labeled 3, and so on. Like swconfig already told us, the CPU is connected on port 5.

Ground rules

  • A port can have three states: Off (unused in the VLAN in question), Untagged, and Tagged.
  • The CPU needs to be tagged in every VLAN. This is indicated by a t behind the digit.
  • A port that will be carrying multiple VLANs (so-called 'trunking') needs to be tagged as well; this applies both to connections to other network devices (e.g. another switch) and to clients that support VLAN tagging. Some switches allow ports to be untagged in one VLAN, and tagged in another; if you're not sure, don't mix.
  • Any port that is only part of one VLAN does not need tagging.
  • VLAN IDs should be consistent across network devices.
  • The VLAN ID will match the virtual interface. Say you create a VLAN with ID 5 on eth0, then your virtual interface (for e.g. layer 3 routing) will be eth0.5. Even if you do not need to manage the VLAN, it's useful knowledge. Many devices already have multiple VLANs in use (e.g. to separate WAN and LAN). The default VLAN is 0; in practice this VLAN is untagged.

Implementation

Now that the foundation is laid, we can get to the tinkering part. My brother has RJ45 jacks in his apartment, but only one in the living room - yet he needed two networked devices, his DVR and the HTPC. Running wires was not an option so he purchased a TL-WR1043ND to use as an AP and switch in the living room. The network is managed by a WNDR3700. Both are running OpenWrt.

To simplify things, the WNDR3700 will have a second physical WAN port (which is a reassigned LAN port). This will be included in a VLAN together with the port that links up to the TL-WR1043ND. Since this uplink port will carry two VLANs - the regular one for the LAN, and the one for the DVR - it needs to be tagged. Our configuration now looks like this:

config switch_vlan
    option device 'rtl8366s'
    option vlan '1'
    option ports '1 2 3t 5t'

config switch_vlan
    option device 'rtl8366s'
    option vlan '2'
    option ports '0 3t 5t'

As you can see I assigned ID 2 to the new VLAN. Port 0 (labeled as 4 on the outside) will be acting as the second WAN port. Port 3 links up the switch. Port 5 is the CPU. Now for the switch - port 1 links it to the router, port 4 connects the DVR to the network. Again we define VLAN 2 and tag port 1 because it's used in both VLANs:

config switch_vlan
    option device 'rtl8366rb'
    option vlan '1'
    option ports '0 1t 2 3 5t'

config switch_vlan
    option device 'rtl8366rb'
    option vlan '2'
    option ports '1t 4 5t'

Because we do not need to manage the VLAN (it is just a physical pathway for the DVR to the ISP's modem), we do not need to create an interface section in /etc/config/network.

Bridged WAN port setup

As an alternative to the second WAN port on the router, you can bridge the WAN port with a single port (that used to be part of the LAN). This leaves you with one more port to use on your LAN, so this is the most efficient solution. We'll be using internal port 3 once more for this.

  • Create a second VLAN with only the link to the switch and the CPU in it.
  • Add the VLAN to the WAN interface by bridging it (you can do this through LuCi if it makes you more comfortable).
  • Since your firewall already has settings for the WAN zone, and the VLAN simply gets added to the WAN interface, you do not have to do anything extra with regards to the firewall.

Your /etc/config/network should now look like this:

config switch_vlan
    option device 'rtl8366s'
    option vlan '1'
    option ports '0 1 2 3t 5t'

config switch_vlan
    option device 'rtl8366s'
    option vlan '2'
    option ports '3t 5t'

config interface 'wan'
    option proto 'dhcp'
    option type 'bridge'
    option _orig_ifname 'eth1'
    option _orig_bridge 'true'
    option ifname 'eth0.2 eth1'

Note that in this case, you do need to use the virtual interface (eth0.2) and explicitly define the interface, unlike with the second WAN port setup.

Keep in mind not all OpenWrt-supported routers support VLAN tagging; first and foremost, the switch should support it, and OpenWrt itself needs to support tagging on the switch as well. To exclude any compatibility issues it's wise to use devices with identical (or very similar) switches. In this case, both the Netgear and TP-Link router use a similar Realtek switch.

A special thanks goes out to glenten and jeffmeden on the OpenWrt forum who gracefully checked my setup for errors and gave some useful info, and to Dima_2005 on the Dutch Gathering of Tweakers forum for sharing his single WAN configuration, also on OpenWrt.