OpenWrt: Your Router, Your Rules - Part 2: WAN Interface Configuration with LuCI

A quick recap:

Part 0 of this series focused on the legal side of the story. According to European regulations on Internet access equipment, in most cases, users have the right to use their own equipment (routers, gateways ecc) instead of the one supplied by their ISP. In that part I also clarified the roles of the ONT, modem, and router, as these terms are often used interchangeably despite referring to different devices.

In Part 0.5 I introduced the networking concepts needed for this guide, including IP address leasing, DHCP, Network Address Translation (NAT), and Carrier-Grade NAT (CGNAT).

In Part 1 I introduced 2 approaches to integrating an OpenWrt router into a home network:

1. placing it behind the ISP's router
2. replacing the ISP's router entirely <-- setup in this article

Also, I explained in details MAC addresses - another way of identifying network interfaces besides IP addresses, which will be important during the configuration process covered in this part. Moreover, in that part the difference between WAN and LAN ports was explained.

---

Starting point of this article: my OpenWrt router, a GL.iNet Flint (GL-AX1800), is connected exactly as it should be, but it has no Internet connectivity.

NB! From this point on, I'll simply refer to my OpenWrt router as Flint.

More details:

• The ISP's router has been disconnected and replaced by my OpenWrt Flint router.
• The ISP's ONT is connected to the router's WAN port using an Ethernet cable.
• The ISP's ONT converts the optical fibre signal into Ethernet (and vice versa). It does not perform routing, NAT, or DHCP ecc.
• From the router's perspective, the first network device it communicates with is the ISP's equipment beyond the ONT. This is the upstream peer for the wan interface.
• Flint provides a local LAN and Wi-Fi network.
• Out-of-the-box, the router has no Internet connectivity.

Scope of this article:

• Configure the Flint's wan interface via LuCI according to the ISP's requirements.
• Fix Internet connectivity.

Glossary:

LuCI is the web user interface of OpenWrt

LAN (Local Area Network) – the private network created by your OpenWrt router. Devices on that LAN use private IP address ranges (such as 192.168.x.x, 10.x.x.x, or 172.16.x.x/12)

WAN (Wide Area Network) – the ISP - managed network that your OpenWrt router connects to in order to gain access to the Internet

DHCP (Dynamic Host Configuration Protocol) server - a network server that automatically provides and assigns IP addresses, default gateways and other network parameters to client devices

---

1. Connecting to the router

To do anything with your OpenWrt router, you first need to access the router itself. OpenWrt routers ship with a default LAN configuration that allows you to join the local network created by them. Looking at the user manual for my Flint, I can identify:

• the default IP address of the router,
• the default Wi-Fi network name (SSID),
• and the default Wi-Fi password.

These are usually included in the shortened version of user manual or are elencati on the sticker on the bottom or back of your router.

I want to configure my Flint's WAN interface through the LuCI web interface. To access my router's LuCI, I first need to join the network created by Flint.

1.1 Joining the router's network

There are two ways to do this:

• Using an Ethernet cable. The classic way. I connect my laptop to one of the router's LAN ports with an Ethernet cable.
• Using Wi-Fi. I connect to the Wi-Fi network broadcast by the router using the default Wi-Fi password printed on the router's label.

My Flint's administration panel (web UI) is available at:

http://192.168.8.1

But simply knowing this address is not enough. To reach it, my device must be part of the same IP network.

1.2 Getting an IP address in router's LAN

My Flint router runs a DHCP server out-of-the-box, so when I connect my laptop (whether by Ethernet or Wi-Fi) Flint automatically assigns an IP address to the device* I'm using (my laptop).

Theory: How one PC/laptop joins multiple networks

Note on "": The IP address is not assigned to the laptop! It is assigned to the laptop's **network device* that I use to connect to my router's network. My laptop has two network-capable devices: an Ethernet adapter and a Wi-Fi adapter. To join my Flint's network over an Ethernet cable, I use my laptop's Ethernet network interface, which receives an IP address from Flint's DHCP server. At the same time, the wireless network interface remains completely independent and can stay connected to a different network (for example, a mobile hotspot) with Internet access while I'm configuring Flint.

Once connected to Flint's LAN 1 port while also using my phone's mobile hotspot for Internet access, running ip a on my laptop shows:

$ ip a
1: lo: Loopback interface (virtual interface that always points back to the computer itself and is used for communication between programs)
    inet 127.0.0.1/8 scope host lo
    ...
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> : ethernet network interface
    link/ether 02:11:22:33:44:55
    inet 192.168.8.196/24
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> : wireless network interface
    link/ether 02:aa:bb:cc:dd:ee
    inet 10.121.99.57/24 ...

The hardware shown is only approximate. The laptop is connected to two independent networks at the same time: enp0s31f6 is the Ethernet interface connected to Flint's LAN, while wlp0s20f3 is the Wi-Fi interface connected to a mobile hotspot.

The laptop contains two network devices (Ethernet and Wi-Fi). Linux exposes them as network interfaces that can be configured independently. Each network interface has its own MAC address, its own IP address, and its own network configuration.

Although this is a single laptop, it is simultaneously connected to two completely separate LANs. They do not overlap or interact with each other directly.

In my example, the Ethernet interface belongs to the 192.168.8.0/24 network, while the Wi-Fi interface belongs to the 10.121.99.0/24 network. Since these networks use completely different private IP address ranges, there is no ambiguity about which network an address belongs to.

What if both networks use 192.168.x.x addresses?

• 192.168.8.57
• 192.168.17.1

Are they on the same network? I can find it out by reading the subnet mask.

Theory: Why /24 matters

The /24 prefix means the first 24 bits identify the network, leaving the last 8 bits for host addresses. In practice, this means devices on my Flint's LAN use addresses in the 192.168.8.x range.

If my laptop had instead received 192.168.8.212/16, that would have mean that Flint's local network is much larger. It would include every address from 192.168.0.0 to 192.168.255.255.

In other words, addresses like 192.168.1.1, 192.168.8.1, 192.168.50.20, 192.168.200.100 - 192.168.x.x - would all be considered part of the same LAN.

This can cause problems. A /16 subnet makes every 192.168.x.x address appear to be local. If your ISP router (for example, if you place your OpenWrt router behind it instead of bypassing it), another router, or a VPN network also uses 192.168.x.x addresses, any device connected to your home network will incorrectly try to reach those addresses directly instead of forwarding the packets to your router. This creates address conflicts and is one of the reasons home routers almost always use a /24 subnet by default.

Now that this little theoretical detour is over, I get back to the configuration. At this point, my laptop is connected to Flint's LAN and has received an IP address from its DHCP server, so both devices are members of the same network. That means Flint is now reachable, and I can access its admin web interface to continue the configuration.

1.3 Accessing LuCI from a web browser

In a web browser I navigate to the path found it in the user manual or on a sticker attached to the device. The first page you'll see is most likely not LuCI, but the vendor's own admin console - web interface. Many OpenWrt-based routers, including GL.iNet devices, ship with a custom interface that makes the initial setup easier while still exposing most of the common settings.

After setting an administrator password, install LuCI, the standard OpenWrt web interface. On GL.iNet devices, this can be done from:

System → Advanced Settings → Install LuCI

LuCI is simply another package that can be installed on OpenWrt router. If your router doesn't come with it preinstalled, you can also install it from the router's shell using the opkg package manager.

My Flint router exposes LuCI at port :8080.

LuCI Web UI Login Page

Gl.iNet Web UI Login Page

---

Before moving on, it's worth taking a closer look at something I've already mentioned briefly: network devices and network interfaces. Understanding the difference between them is essential, because from this point onward almost everything you'll configure in OpenWrt revolves around them.

2. Theory: Physical network devices vs. network interfaces

Earlier I showed that my laptop has 2 networking adapters: an Ethernet adapter and a Wi-Fi adapter. Debian exposes both as networking interfaces that can be configured independently.

An OpenWrt router follows the same principle, but instead of just one Ethernet adapter and one Wi-Fi radio, it typically contains multiple Ethernet ports, one or more Wi-Fi radios and an internal Ethernet switch. All traffic entering or leaving the router is ultimately processed by the Linux kernel running on its CPU.

Unlike a typical Linux distribution, OpenWrt separates networking into Devices and Interfaces. Understanding the difference between them is essential because the next configuration steps use both.

Router teardown view of the GL.iNet Flint 2 (right side) taken from GL.iNet GL-MT6000 “Flint 2” WiFi 6 router review by Jean-Luc Aufranc. The labels are simplified and only approximate the internal architecture for explanatory purposes. Don't throw pantofole at me for the oversimplification, thx

OpenWrt separates network configuration into Network Devices and Network Interfaces. Despite their names, both are software abstractions managed by Linux. Configuring a network device is not limited to changing properties of physical hardware such as an Ethernet controller. An OpenWrt network device can represent physical hardware (eth0), a bridge (br-lan), a VPN tunnel (wg0), or even a completely virtual device created entirely in software, such as the VLAN device that I'll create later in this article.

In other words, network devices represent the networking endpoints themselves (eth0, br-lan, eth1 ecc). They expose low-level networking properties configuration. Network interfaces (wan, lan, guest ecc) sit one level above them. They describe how one of those network devices should connect and participate to a network, for example by using DHCP or a static IP configuration.

The confusion between physical network interfaces and OpenWrt interfaces is common enough that the OpenWrt documentation has an article dedicated to clarifying it:

An “Interface” in the OpenWrt configuration must not be mixed up with a physical interface. It is tempting. [...]
To clarify things (hopefully) let's avoid the term interface and replace it with something more neutral. What we actually configure in OpenWrt could be named a “Connector”. The configuration of a “Connector” combines all properties that are required to attach the device running OpenWrt to a network. [I'll call a physical device a “controller”]. This include a physical device and setup information that configures the controller in such a way that it allows the device to join the network.Clarifying the term "Interface"

---

Theory: A bit on OSI model - the layer where connectivity fails

The OSI (Open Systems Interconnection) model is a conceptual framework that divides network communication into 7 layers, each responsible for a specific part of sending and receiving data.

7 Application → HTTP, DNS, DHCP
6 Presentation → Encryption, compression
5 Session → Managing communication sessions
4 Transport → TCP, UDP
3 Network → IPv4, IPv6, routing
2 Data Link → Ethernet, MAC addresses, VLANs
1 Physical → Cables, fibre, electrical/optical signal

In my setup, Layer 1 is already working correctly. The Ethernet link between my Flint router and the ONT is up, the ONT converts Ethernet frames into GPON frames so they can travel over the optical fibre, and at the ISP's side they are converted back into Ethernet frames.

The next step is Layer 2, the Data Link layer, where Ethernet operates.

Right now, this is exactly where my connection fails. My router is sending Ethernet frames, but the ISP discards them before they can be processed further. As a result, my router never receives an IP address or any information about the ISP's network it is trying to join.

3. Layer 2 problem: one cable, multiple networks

My router constantly sends and receives Ethernet frames. Every Ethernet frame contains a destination address, a source address, an EtherType field, a payload, and a CRC.

My router receives the packet encapsulated in an Ethernet frame on one of its LAN interfaces. It then removes the incoming Ethernet header, performs a routing lookup to determine where the packet should go, and creates a new Ethernet frame for transmission through its WAN interface.

With my setup:

Device connected to Flint's LAN via Wi-Fi
    ↓
OpenWrt Flint router
    ↓
Ethernet cable
    ↓
ONT
    ↓
GPON over optical fibre (My ISP's notation)
    ↓
ISP network
    ↓
Internet

The ONT converts Ethernet frames into GPON frames so they can travel over the optical fibre. At the ISP's side, they are converted back into Ethernet frames and continue through the ISP's network.

So, why does no packet destined for the Internet ever reach it? Why can't my Flint router EVEN join the ISP's network?

As mentioned in the first part of this series, deploying network infrastructure is extremely expensive. ISPs therefore try to make the best possible use of their physical infrastructure. Instead of dedicating one physical cable to one logical network or service, the same cable can carry traffic belonging to multiple independent networks.

In that scenario, the source and destination MAC addresses alone are no longer enough. They identify who is communicating, but not which logical network or service the frame belongs to. An additional identifier is needed.

Theory: IEEE 802.1Q and VLAN tags

This problem is solved by the IEEE (Electrical and Electronics Engineers) 802.1Q standard, which introduced Virtual Local Area Networks (VLANs) for Ethernet networks. This 802.1Q standard inserts a small 4-byte tag into every Ethernet frame. Among other information, this tag contains a 12-bit VLAN Identifier (VID), which tells network equipment which logical network the frame belongs to.

My ISP's requirement: VLAN 835

In fact my ISP Fastweb requires tagged modality:

In case of BS-GPON fibre, the Ethernet WAN port of the router chosen by the customer as an alternative to the one supplied by Fastweb must be connected to the Optical Network Terminal (ONT), which is provided by Open Fiber during service activation, using a Category 5e or higher Ethernet cable. The connection must operate in tagged mode (VLAN ID 835; CoS 0 for data traffic and CoS 1 for voice traffic). Modem-router alternativi e Fastweb

4. Configuring the WAN port to add VLAN tags to outgoing Ethernet frames

At this point, I know that Fastweb expects every Ethernet frame sent by my router to carry VLAN ID 835.

However, an Ethernet WAN port is just that - an Ethernet port. By default, it sends ordinary Ethernet frames without any VLAN tag. Before my router can communicate with the ISP, I need to configure the WAN side so that every Ethernet frame leaving the WAN port is automatically tagged with VLAN ID 835.

To see what an ordinary Ethernet frame looks like, here is captured traffic on my router's LAN:

# tcpdump -i br-lan -e -vv
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
...
21:14:23.886143 3c:52:82:1a:7f:10 (oui Unknown) > 8e:b4:19:c3:55:d2 (oui Unknown), ethertype IPv4 (0x0800), length 66: (tos 0xb8, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)

Timestamp: 21:14:23.886143
Source MAC address: 3c:52:82:1a:7f:10
Dest MAC address: 8e:b4:19:c3:55:d2
Ethertype: IPv4

Notice that there is no 802.1Q VLAN header. This is an ordinary Ethernet frame. After configuring tagging, a capture on the physical WAN port looks like this:

# tcpdump -i eth0 -e -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:56:22.450934 ac:91:a1:2f:48:6c (oui Unknown) > 4c:16:fc:21:b8:4d (oui Unknown), ethertype 802.1Q (0x8100), length 287: vlan 835, p 0, ethertype IPv4 (0x0800), (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 269)

Timestamp: 21:56:22.450934
Source MAC address: ac:91:a1:2f:48:6c (Flint router)
Dest MAC address: 5a🇩🇪44:91:07:b3 (ISP's device)
Ethertype: 802.1Q
Vlan: 835
Inner EtherType: IPv4

---

---

So, how do I make every Ethernet frame leaving the WAN port carry VLAN ID 835? The physical WAN port on my router is represented by OpenWrt as network device eth0. At the moment, it transmits ordinary Ethernet frames. OpenWrt allows me to create another logical network device based on eth0. This new device will automatically insert VLAN ID 835 into every outgoing Ethernet frame while still using the same physical Ethernet port. Once that VLAN-aware network device exists, I'll simply tell the existing wan interface to use it instead of the original eth0.

4. Creating a logical VLAN-aware network device based on the WAN port

In LuCI, I navigate to Network → Interfaces → Devices (the second tab).

This is what I see:

Since I need to deal with virtual networks, I cannot modify the existing network device eth0 to do what I need. Instead, I have to create another logical (software) device that will be based on eth0.

I click on "Add device configuration..." (in the left bottom corner below the list of existing devices).

This new logical device will use eth0 as its physical transport, but it will automatically insert VLAN ID 835 into every outgoing Ethernet frame and accept incoming frames tagged with VLAN 835.

You can think of it as adding another logical lane to the same physical cable. Physically, there is still only one Ethernet cable between my router and the ONT, but logically multiple independent networks can coexist on it. The ISP uses exactly the same principle on its own infrastructure: one physical link can carry multiple logical services, distinguished by their VLAN tags.

New device configuration:

1. Device type: VLAN (802.1q)

1. Base device: eth0 (WAN port)

1. VLAN ID: 835

That is the key configuration.

1. Device name: eth0.835 (following Dot1q notation)

2. MAC address

...aaand here's something that solves the next potential problem!

4.1 ISP access control: MAC address filtering

A quick recap on MAC addresses. Unlike IP addresses, MAC addresses are used only on the local link. Every network device has its own MAC address, which identifies it on the local Ethernet network. Switches use MAC addresses to deliver Ethernet frames to the correct device. They are therefore fundamental to Layer 2 communication.

Even though MAC addresses are unique and a little special because they can reveal information about the manufacturer of a network device, they are not necessarily glued or engraved into the hardware forever. Routers in particular can change or clone the MAC addresses used by their network devices.

It is important to distinguish a computing device from a network device. My laptop is one computing device, but it contains an Ethernet port card and a Wi-Fi network card. Each network card has its own MAC address. The laptop itself does not have one cumulative MAC address representing the whole machine.

The same applies to a router. Remember I showed earlier the intercepted Ethernet frames from the LAN and WAN sides? The source of these frames was my Flint router, but the frames were sent through two different network devices (bridge LAN and eth0), each with its own MAC address.

After fixing the VLAN tagging, my router finally received an IP address. However, Internet access was still restricted. Instead of reaching the Internet, every HTTP request I made with curl was redirected to a Fastweb page asking me to register my router's MAC address.

The ISP's logic is roughly this: 1 Internet contract === 1 Internet-facing device. The contract is associated with your customer account, and the router is identified by the MAC address of its WAN network device. Any other MAC address trying to use that connection is treated as an unknown device and is redirected to the registration page instead of being granted full Internet access.

There are two ways to solve this:

1. Register the MAC address of your new router (the one shown by default for eth0 in "Add device configuration..." ).
2. Clone the MAC address of the ISP router.

MAC cloning sounds much fancier than it really is. It is essentially just a copy paste operation. I simply copied the MAC address printed on the sticker on the back of my ISP's router and entered it into the MAC address field for eth0.835. The sticker printed it as twelve hexadecimal characters without any separators, so I just added a colon every two characters. Remember that a MAC address is made up of hexadecimal digits (0 - 9 and A - F).

4.2 Back to the configuration!

New device configuration:

...

1. MAC address

copied from ISP's router.

6,7. MTU and TX queue length

Retype placeholder (MTU 1500 and TX length 1000) values.

Voila!

At this point, the VLAN-aware network device exists, but nothing is using it yet. OpenWrt still sends WAN traffic through the original eth0. The last step is to tell the interface that handles WAN traffic (all traffic destined for the upstream ISP's network) to use the newly created software level eth0.835 device instead of the default network device eth0.

5. Configuring the wan network interface

This is the list of interfaces that my router has already configured that I see in Network → Interfaces in LuCI:

It is visible that wan interface isn't functioning well yet. It has not obtained an IPv4 address, while the lan and guest interfaces have IPv4 addresses. I can also see that the IPv4 protocol configured for wan is DHCP client. This means the router requests one from the DHCP server on the upstream network - my ISP's network.

Since I haven't yet told the wan interface to use the VLAN-aware network device (eth0.835), those DHCP requests are still leaving through the untagged eth0 device. Fastweb expects VLAN ID 835 on every frame, so it simply ignores them. As a result, no DHCP lease is offered, and the wan interface remains without an IP address

I click on "Edit" button of wan interface to modify its configuration.

1. Protocol
   DHCP client

2. Device
   I change eth0 to "Software VLAN eth0.835

3. Disabled
   unchecked

4. Bring up on boot
   checked

5. Hostname to send when requesting DHCP
   Do not send a hostname

---

I'll also configure a few additional settings. If you look at the available tabs for the wan interface, you can see that an OpenWrt interface is responsible for much more than simply how to connect to some network. For example, there's a Firewall Settings tab where the interface can be assigned to one of the firewall zones. Firewall zones control how traffic entering or leaving through this interface is filtered. I'll leave this unchanged and keep the default configuration shipped with my router.

You'll also see a DHCP Server tab. Although every interface can have one, enabling a DHCP server on the wan interface usually makes no sense because wan is a client of the ISP's network, not the owner of it. On the lan interface, however, it's a completely different story. The lan interface represents the router's local network, built on top of virtual bridge , which "merges" all LAN Ethernet ports and Wi-Fi radios. Here, running a DHCP server is exactly what I want.

5.1 Instruct wan interface to use custom DNS servers

If you open the Advanced Settings tab, you'll find more configurations. When using DHCP, the upstream network (in case of wan interface - ISP's one) doesn't just provide an IP address to my Flint. A DHCP lease can also advertise the default gateway, DNS servers, subnet mask, lease time, and other network parameters.

OpenWrt lets me decide whether to accept those parameters or override them. For example, I can and I want to ignore the DNS servers advertised by the ISP and instead configure DNS resolver of my choice.

Why?

The Domain Name System (DNS) is the phonebook of the Internet. When users type domain names such as ‘google.com’ or ‘nytimes.com’ into web browsers, DNS is responsible for finding the correct IP address for those sites. Browsers then use those addresses to communicate with origin servers or CDN edge servers to access website information. This all happens thanks to DNS servers: machines dedicated to answering DNS queries.What is DNS server

Why should you care which DNS server you use

If you're comfortable configuring DNS servers directly on each of your devices, changing the router's DNS settings may not seem very important.

For example, my Debian laptop is configured to use Quad9 (9.9.9.9) directly. Whenever I type https://dev.to/ into my browser, my laptop sends the DNS query straight to Quad9 nameserver, regardless of which DNS servers my router uses.

Most devices, however, aren't configured this way. A typical phone connected to home Wi-Fi simply uses the router as its DNS resolver. The phone doesn't know where to send DNS queries on the Internet; it just asks the default gateway - my Flint router.

Phone
   │
   │ "Where is dev.to?"
   ▼
Flint router
   │
   │ forwards the query
   ▼
Configured DNS server

If I accept for wan interface the DNS servers advertised by my ISP via DHCP, every device on my network that relies on the router for DNS will end up using those servers. I may not know where they're located, who operates them, how fast they are, or what _privacy policy _they follow.

A bit on privacy policy....

A DNS server is just another server on the Internet, and your router (or your device) is its client. Every time it receives a DNS query, it necessarily sees who is asking and which domain name is being resolved. Conceptually, from the DNS server's point of view, every request looks something like this:

Client IP: 71.71.89.12
Query: something-maybe-i-would-like-to-be-private.net
Response: 203.0.113.42

Any DNS resolver itself deliberatly learns the domain names you ask it to resolve. That's one reason many people choose a DNS provider whose privacy policy they trust. In my case it is quad9 9.9.9.9

How to:

---

It is done!!!

All that's left is to click Save followed by Save & Apply (left bottom corner) Before applying the changes, LuCI even shows you exactly what is about to be modified. If you're curious, click "Changes" in the top-right corner. You'll see the underlying configuration changes that OpenWrt is about to apply.

This is one of my favourite features of LuCI. Although it's a web interface, it's really just a graphical frontend for OpenWrt's configuration system. Looking at the pending changes is a great way to gradually learn how the same configuration could be performed from the command line over SSH, without using the web interface at all.

After applying the changes, the wan interface successfully obtains an IPv4 address from my ISP (Fastweb) DHCP server. The router is now connected to the ISP's network through the VLAN-aware network device eth0.835 that present itself with the correct MAC address approved by my ISP, and Internet connectivity is finally up.

Opening Status → Overview confirms that everything is working as expected.

I can clearly see that I am CG-NATed, my IP address is from the pool of Private IP addresses.