DEV Community: aL

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

aL — Tue, 28 Jul 2026 18:33:17 +0000

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:

placing it behind the ISP's router
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:

Device type: VLAN (802.1q)

Base device: eth0 (WAN port)

VLAN ID: 835

That is the key configuration.

Device name: eth0.835 (following Dot1q notation)
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:

Register the MAC address of your new router (the one shown by default for eth0 in "Add device configuration..." ).
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:

...

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.

Protocol
DHCP client
Device
I change eth0 to "Software VLAN eth0.835
Disabled
unchecked
Bring up on boot
checked
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.

OpenWrt: Your Router, Your Rules - Part1: Keep or Bypass Your ISP's Router?

aL — Mon, 20 Jul 2026 15:44:21 +0000

The previous two parts, Part 0 and Part 0.5, were intentionally numbered that way because they were mostly theoretical. They weren't directly about OpenWrt, but they provide the foundation needed to understand what comes next.

By now, I hope it's clear what a router actually is, what it isn't, and that you won't confuse it with a modem or an ONT anymore. If your ISP supplied you with a single all-in-one gateway, you should also understand what is that device. This is important because, before start using your own OpenWrt router, you first need to understand where it fits into your home network.

I also covered NAT and Carrier-Grade NAT (CGNAT). CGNAT is useful to know about because it may limit what you can do with your connection, for example if you want to host services at home. NAT, however, is fundamental Understanding how it works will make the rest of this series much easier to follow.

Now it's finally time to start using OpenWrt. In this part I'll show how to introduce an OpenWrt router into an existing home network in the two ways:

Replacing the ISP's router.
Connecting your OpenWrt router behind the ISP's router, keeping the ISP's devices in place while adding your own router as another node in the network.

By the end of this part, your OpenWrt router will be physically connected and ready for configuration in the following chapter.

I have a GL.iNet router model Flint (GL-AX1800).

It's a bit old (currently the newest model is Flint 4), but gold router (still). It comes with GL.iNet's fancy user-friendly web interface and of course OpenWrt OS with its configuration interface LuCI.

Little recap:

OpenWrt is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application (OpenWrt GitHub Repo)

GL.iNet's devices already come with OpenWrt installed, so there is no need to flash the firmware yourself. GL.iNet base their router's firmware on a specific OpenWrt release (or release branch), backport fixes as needed, and then add their own packages and interface. They also provide a clean and beginner-friendly web interface that exposes most of the features home users need.

If you need more advanced functionality, you're not locked into that interface. You can always access the standard OpenWrt tools, either through LuCI, OpenWrt's own web interface, or by connecting to the router over SSH.

I've been very happy with my GL.iNet devices, but they are by no means the only routers capable of running OpenWrt.

For that reason, whenever possible I'll show both approaches: how to perform a task using the GL.iNet interface and how to do the same thing using standard OpenWrt (LuCI or the command line). That way, the guide remains useful even if you're using a different router.

1. Connecting your OpenWrt router

Before connecting your router, it's important to understand what its different ports are used for and where each one should be connected in your home network.

1.1 LAN and WAN ports

LAN stands for Local Area Network, while WAN stands for Wide Area Network.

My GL.iNet Flint router has 4 LAN ports and 1 WAN port.

Having 4 LAN ports simply means I can connect up to four wired Ethernet devices directly to the router. Those devices don't have to be only PCs or laptops. They could just as well be another router or NAS or any other Ethernet-capable device.

So what makes the WAN port different?

The WAN port is used to connect the router to an upstream network device. In my case, an Ethernet cable runs from the WAN port to the ONT. The ONT converts the optical signal from the fiber into Ethernet frames, allowing my router to communicate with my ISP.

On many home routers there is only one WAN port. Manufacturers often place it slightly apart from the LAN ports or give it a different color, commonly blue, to make it easier to identify.

At first glance, the WAN and LAN ports appear to be completely different. But a WAN port and a LAN port are, in most cases, physically identical Ethernet ports.

The real difference lies in how the router's operating system configures them. The port itself is just a physical connector. Behind it is exposed to the operating system as one or more network interfaces.

On my router, all 4 LAN ports belong to one logical network interface (a bridge called br-lan in OpenWrt), while the WAN port is assigned to a separate interface - wan. Because they are separated, OpenWrt allows to configure and manage them differently.

Screenshot from LuCI: Network --> Interfaces

The LAN interface is configured to allow connected devices to communicate with each other.

The WAN interface, on the other hand, is configured to communicate with the upstream network and it belongs to a separate firewall zone considered untrusted.

The firewall, routing table, NAT and many other networking rules depend on this distinction.

This is why you generally can't plug your ONT into a LAN port or connect your PC to the WAN port and expect everything to work automatically. The hardware itself is usually capable of doing either job, but the software has been configured with a very specific role for each interface.

One of the strengths of OpenWrt is that these roles are not fixed. If your hardware supports it, you can reassign ports, create additional interfaces, use VLANs, or even turn a LAN port into a WAN port. The labels printed on the router's case are simply the manufacturer's default configuration, they are not permanent hardware limitations.

1.2 Setup 1: Connecting router behind the ISP's router

ISP's router -> your router" width="800" height="440">

The ISP router stays exactly where it is, while your OpenWrt router is connected to one of its LAN ports. By default, your OpenWrt router simply receives a private IP address from the ISP router via its DHCP and creates ANOTHER network behind it. In this case you can connect devices to both - to your ISP's router and you your OpenWrt router.

Pros:

Usually plug-and-play. No ISP configuration is required.
Little risk of accidentally breaking your Internet connection.
If your ISP router provides IPTV or VoIP, those services continue working without any additional configuration.
....mmm that's all

Cons:

Two routers performing routing (Double NAT)
Additional re-routing of packages step from your devices and the Internet.
Limited control over the ISP's router

The ISP router remains the gateway to the Internet. Most ISP routers run proprietary firmware with only a few settings exposed to the user. If something doesn't work as you would prefer, there is often very little you can inspect or change.

You're essentially dealing with a black box: no access to detailed logs, no advanced firewall configuration, no any extra feature and usually all you have is 254 addresses for your home devices being the part of a unique LAN.

Vendor-specific quirks

Some routers implement unusual firewall rules that can impede a lot using your home network at maximum. These rules can impede sometimes even streaming of stuff from your phone to TV even though they are both connected to the same network. Or you can have troubles with playing online together with someone located elsewhere.

My experience with my ISP - Fastweb:

The first surprise was that their router administration happens through a mobile app. Personally, I wasn't comfortable with that. I prefer managing my networking equipment locally.

The Wi-Fi performance also wasn't great in my home. Signal strength dropped significantly in the rooms farthest from the router, and the throughput was noticeably lower than what I later achieved with my GL.iNet Flint.

My phone would randomly disconnect and re-connect from Wi-Fi every few hours. I never discovered the exact cause.

With this setup there is one concern:

Private IP conflicts. If both the ISP router and your OpenWrt router use the same private subnet (for example, 192.168.1.0/24), routing won't work correctly.

No conflict:

Internet
    │
   ONT
    │
ISP Router: 192.168.1.1/24
    │
OpenWrt WAN: 192.168.1.100
    │
OpenWrt Router: 192.168.8.1/24
    │
Devices: 192.168.8.x

Conflict:

ISP Router LAN:      192.168.1.0/24

OpenWrt WAN:         192.168.1.100

OpenWrt LAN:         192.168.1.1/24   ❌

Fortunately, OpenWrt usually detect this situation during the initial setup and automatically choose a different LAN subnet.

1.3 Setup 2: Connecting router in place of the ISP's router

Instead of connecting your OpenWrt router behind the ISP's router, you remove the ISP router entirely and connect your router directly to the ONT (or whatever device terminates your ISP's connection).

If you live in the European Union, this is your right under the Router Freedom / Modem Libero regulations discussed in Part 0 of this series.

The challenge is usually getting the connection parameters right. Depending on your ISP, you may need to configure DHCP, PPPoE, VLANs or settle the MAC address.

your router" width="800" height="440">

MAC address

A MAC (Media Access Control) address is a hardware identifier assigned to a network interface.

Unlike an IP address, which depends on the network a device is connected to and may change over time, a MAC address is normally programmed into the network interface by the manufacturer and remains the same throughout the device's lifetime.

A MAC address consists of 48 bits and is usually written as six hexadecimal numbers separated by colons.

40:A5:EF:12:34:56

Although MAC addresses are designed to uniquely identify network interfaces, they are only used for communication within a single local network. Ethernet switches use MAC addresses to decide which physical port a frame should be forwarded to. Routers, on the other hand, use IP addresses to move packets between different networks.

Suppose your laptop wants to send data to another computer connected to the same switch. It creates an Ethernet frame whose destination is the other computer's MAC address.

But what if the destination is somewhere on the Internet?

Your laptop sends the frame to your router's MAC address. The router removes the Ethernet frame, examines the IP packet inside it, decides where it should go next, and then creates a brand-new Ethernet frame with different source and destination MAC addresses for the next network segment.

The MAC address ensures your device is recognized on the local network, while the IP address helps your device communicate effectively on the broader internet.

MAC addresses never travel across the Internet. They are only used for communication between devices that share the same local network.

NB! A MAC address identifies a network interface, not an entire device.

Then why does the ISP care about router's MAC address?

Some ISPs associate your connection with the MAC address of the device connected to their network. If a different MAC address suddenly appears, the ISP may refuse to provide Internet access until the new device is registered or authenticated.

This is why replacing the ISP router sometimes results in an apparently correct configuration that still has no Internet connectivity.

If this is the case how you ISP handles connectivity, then you sign the contract with ISP for Internet service -> your contract = 1 registered MAC address of the router they provided to you. When you replace the ISP router with your own, the ISP sees a completely different MAC address and refuse to provide Internet access until the new device's MAC address is registered.

You have two options: communicate to the ISP your router's MAC address or make your router present itself with registered MAC address of router provided by ISP that is indicated on the sticker on the back part of ISP's router.

OpenWrt makes this easy. You can configure the WAN interface to use any MAC address you choose, including the MAC address of the original ISP's router. This process is known as MAC cloning. Despite the name, nothing is actually copied to the hardware. OpenWrt simply instructs the network interface to present a different MAC address whenever it communicates with the ISP.

In my case, replacing the Fastweb router was almost straightforward. DHCP worked, the router obtained an IP address, and all the settings appeared to be correct. However, there was still no Internet connectivity. After cloning the WAN MAC address of the original Fastweb router, the connection immediately started working.

Alllright! You can follow either of the two setups presented earlier.

In the next part I will demonstrate Setup 2, where the ISP router is removed and replaced with my OpenWrt router. Firstly, I connect the WAN port of my GL.iNet Flint directly to the Ethernet port of my ONT....

OpenWrt: Your Router, Your Rules - Part 0: Il diritto di scegliere il tuo router

aL — Sat, 18 Jul 2026 11:10:47 +0000

Inizialmente avevo pensato di scrivere una guida pratica su come configurare più SSID associati a VLAN differenti utilizzando OpenWrt (via LuCI). Poi, però, ho iniziato ad approfondire l'argomento e... è andata a finire come al solito. Ci sono semplicemente troppi concetti da chiarire prima. Prometto che le prossime parti saranno finalmente dedicate alla configurazione pratica.

Questa parte interesserà probabilmente soprattutto chi vive nell'Unione Europea, e ancora di più chi vive in Italia. Farò infatti riferimento alla normativa europea per spiegare brevemente come gli Internet Service Provider (ISP) forniscono il servizio Internet e, in particolare, come gestiscono l'apparecchiatura che installano nelle nostre case. Vivendo in Italia, ho avuto modo di familiarizzare con alcune particolarità del mercato italiano.

Oggi si parla molto della privacy di smartphone, computer, applicazioni e sistemi operativi. Ma quando si comincia davvero a interessarsi alla privacy, al networking e a capire che fine fanno i propri pacchetti una volta usciti dal computer, prima o poi l'attenzione finisce inevitabilmente su quel dispositivo che se ne sta silenzioso in un angolo della casa...

Questa guida è pensata per chi vuole capire davvero come funziona la propria rete domestica e prenderne il controllo utilizzando un router compatibile con OpenWrt.

OpenWrt non è propriamente uno strumento per chi parte completamente da zero, ma è molto meno complicato di quanto possa sembrare. Inoltre dispone di un'interfaccia web (LuCI) che rende la configurazione decisamente più accessibile.

Se sei arrivato fin qui, probabilmente possiedi già un router compatibile con OpenWrt oppure stai pensando di acquistarne uno. Magari negli anni hai raccolto qualche nozione di networking qua e là e senti che è arrivato il momento di fare un passo in più, ma hai ancora qualche dubbio. Oppure hai paura di modificare qualcosa perché temi di rompere la connessione o di fare qualcosa che il tuo ISP non permette.

Ho scritto questa guida perché mi sono ritrovato a raccogliere informazioni sparse tra decine di fonti diverse e ho pensato che valesse la pena riunirle in un unico posto.

Credo anche che gli Internet Service Provider dovrebbero essere molto più trasparenti riguardo ai servizi e alle apparecchiature che offrono e non dovrebbero mai limitare la libertà dei clienti di scegliere il proprio router o di cambiare operatore. Quando questo non accade, per fortuna esiste una comunità di persone che condivide conoscenze ed esperienze. Questo articolo vuole essere un piccolo contributo a quella comunità.

Per i lettori italiani, spero che questa guida possa essere utile per capire quali domande fare e quali aspetti valutare prima di scegliere o cambiare operatore Internet.

In questa parte parlerò di:

Parte 0
 ├ Cosa il tuo ISP può (e non può) pretendere
 ├ OpenWrt
 ├ Come arriva Internet a casa
 └ ONT, modem e router: che differenza c'è?

1. Internet Service Provider e normativa europea

ISP è l'acronimo di Internet Service Provider, cioè l'operatore che fornisce l'accesso a Internet.

Quando si vuole una connessione Internet a casa, invece di affidarsi alla rete mobile (che spesso offre meno traffico disponibile, una copertura meno stabile e velocità inferiori), il primo passo è capire quali operatori sono disponibili nella propria zona.

Nella maggior parte dei casi la scelta non è enorme, ma avere a disposizione tre, quattro o cinque operatori è piuttosto comune. In generale, più grande è la città in cui vivi, maggiori saranno le alternative.

Nell'Unione Europea il mercato delle telecomunicazioni è regolato da norme sulla concorrenza e sulla tutela dei consumatori. L'obiettivo è semplice: quando hai bisogno di un servizio, in questo caso dell'accesso a Internet, devi poter scegliere tra più operatori che competano tra loro su prezzo, velocità e servizi offerti.

Non tutte le offerte "Internet casa a 27,99 € al mese" sono uguali.

1.1 L'accesso a Internet è un mercato un po' particolare

Dal punto di vista economico, il servizio di accesso a Internet è un bene piuttosto particolare.

L'infrastruttura fisica su cui si basa presenta molte caratteristiche tipiche di un monopolio naturale, proprio come la rete ferroviaria, quella elettrica o quella stradale. Costruire questa infrastruttura richiede investimenti enormi, motivo per cui duplicarla completamente per ogni operatore sarebbe economicamente irrealistico.

Con "servizio Internet" mi riferisco all'infrastruttura e ai servizi che consentono di accedere alla rete globale, non al World Wide Web, cioè ai siti web, alle applicazioni e ai contenuti disponibili online.

Internet non è composta da un unico gigantesco cavo che collega tutto il pianeta, ma lo stesso principio vale per gran parte della rete.

Le dorsali nazionali e internazionali, le reti in fibra ottica e perfino molte infrastrutture wireless richiedono investimenti enormi. Per questo motivo è molto comune che operatori diversi condividano parte dell'infrastruttura oppure si affittino reciprocamente l'accesso alla rete, invece di costruirne una completamente nuova.

In altre parole, la concorrenza esiste, ma spesso riguarda il servizio commerciale più che l'infrastruttura fisica sottostante.

Questo rende il mercato decisamente più complesso e, in molti casi, mette il cliente in una posizione di svantaggio informativo.

1.2 Cambiare operatore in Italia

In Italia i principali operatori di rete fissa sono TIM, Vodafone, Fastweb e WindTre.

Le norme europee sulla concorrenza non garantiscono soltanto la libertà di scegliere un operatore quando si sottoscrive un contratto, ma anche quella di cambiarlo successivamente senza dover affrontare penali irragionevoli, anche nel caso in cui si stiano utilizzando apparecchiature fornite dall'operatore stesso.

Queste tutele sono recepite e applicate da AGCOM (Autorità per le Garanzie nelle Comunicazioni).

Uno dei principi fondamentali è che, quando si decide di cambiare operatore, i costi di migrazione o di cessazione del contratto non possono superare il valore del canone mensile medio oppure i costi realmente sostenuti dall'operatore, scegliendo l'importo più basso tra i due.

Inoltre, gli operatori non possono pretendere la restituzione indiscriminata di tutti gli sconti promozionali applicati durante il contratto: qualsiasi eventuale rimborso deve essere proporzionato ed equo.

Non è sempre stato così.

Fino a qualche anno fa alcuni operatori rendevano il cambio di gestore estremamente oneroso imponendo costi di recesso molto elevati, scoraggiando di fatto la concorrenza.

AGCOM on Switching operator and terminating contract

Fin qui tutto molto bello. Ma c'è un dettaglio interessante.

Gli utenti possono continuare a pagare le rate residue relative ai beni o ai servizi acquistati anche dopo aver esercitato il recesso, purché il piano di rateizzazione non superi i 24 mesi. (Charges for terminating contract)

Ed è proprio qui che nasce una domanda interessante. Di quale bene stiamo parlando?

Se il contratto per il servizio Internet è stato chiuso e il cliente è passato a un altro operatore, il servizio non esiste più. Che cosa rimane allora da pagare? La risposta è: l'apparecchiatura fornita dall'ISP.

1.3 L'apparecchiatura fornita dal tuo operatore

L'apparecchiatura fornita dall'operatore.

Per un normale utente domestico significa quasi sempre un modem, un router (oppure un unico dispositivo che integra entrambe le funzioni) e qualche cavo. MA... Se non stiamo parlando di un'azienda con armadi rack pieni di apparati di rete, che tipo di dispositivo così costoso stiamo pagando a rate per ben 24 mesi? Ed ecco che entra in scena il protagonista di questo articolo:

il router fornito dall'ISP.

1.4 Il modem TIM da 240 euro

Prendiamo come esempio una delle attuali offerte fibra di TIM (20 lug 2026).

Access date: 10 July 2026, 07:07 PM [Source](https://www.tim.it/fisso-e-mobile/fibra-e-adsl/fibra-internet-casa)

Aprendo la sezione Dettagli costi, compare questa voce:

MODEM TIM HUB+ (per tecnologia FTTC), MODEM TIM HUB Pro (per tecnologia FTTH)
240€ rateizzati in 48 rate mensili da 5€.Nei primi 24 mesi dall’attivazione dell’offerta ti sarà applicato uno sconto di 5€/mese sull’acquisto del modem, pertanto, il costo complessivo del prodotto sarà di 120€ anziché 240€. (Source accessed 10/07/2026, free translation)

In caso di recesso prima di 48 mesi saranno dovute le rate mancanti del modem TIM (unicamente quelle a titolo oneroso e non quelle in promo).

A prima vista 240 € non sono necessariamente un prezzo assurdo. Un buon gateway domestico (cioè un dispositivo che integra ONT e router) può tranquillamente costare quella cifra. Il punto, però, è un altro.

Vale davvero 240 €? E, soprattutto: è davvero il dispositivo che vuoi acquistare?

Guardiamo la scheda tecnica.

Tre porte LAN. Una porta WAN. Wi-Fi dual band. E poi? Che processore monta? Quanta memoria RAM ha? Quanta storage? Quale chipset Wi-Fi utilizza? Supporta OpenWrt?

Come dovrebbe un cliente capire se il dispositivo vale davvero quella cifra con una scheda tecnica così scarna? Probabilmente nessuno comprerebbe spontaneamente un router da 240 € in un negozio online se la descrizione si limitasse a queste informazioni.

E non perché sia necessariamente un cattivo dispositivo. Potrebbe anche essere un ottimo gateway.

Il problema è che il cliente non dispone delle informazioni necessarie per valutarlo consapevolmente.

1.5 Hai il diritto di usare il tuo router

Ed è qui che entra in gioco la normativa europea. Il diritto dell'Unione Europea tutela la libertà degli utenti di scegliere l'apparecchiatura con cui accedere a Internet.

In base al Regolamento (UE) 2015/2120 sull'accesso a Internet aperta, gli operatori non possono obbligarti a utilizzare il loro router, purché il dispositivo scelto sia compatibile con la loro rete e rispetti i requisiti tecnici previsti.

In pratica, questo significa che l'operatore:

non può rifiutarsi di collegare un dispositivo scelto dal cliente se conforme agli standard tecnici;
non può applicare costi aggiuntivi né degradare la qualità del servizio perché utilizzi un router diverso dal suo;
deve fornire tutte le informazioni tecniche necessarie per configurare un router alternativo;
se il router fornito integra anche l'ONT per una connessione FTTH, deve consentire al cliente di richiedere un ONT esterno.

Naturalmente non posso parlare dell'esperienza di tutti gli operatori. Nel mio caso utilizzo Fastweb. Quando ho attivato la linea mi sono stati forniti due dispositivi distinti:

un ONT;
un router.

Del router Fastweb non faccio uso. Utilizzo invece il mio router personale, mentre continuo a usare l'ONT fornito dall'operatore, perché è il dispositivo che termina la connessione in fibra ottica. Ed è una configurazione comune, oltre che, nella maggior parte dei casi, la soluzione migliore.

A questo punto dovrebbe essere chiaro un concetto fondamentale.

Utilizzare la propria apparecchiatura di rete non è un favore concesso dall'operatore, ma un diritto riconosciuto dalla normativa europea. Se il router fornito dal tuo ISP non ti soddisfa, non sei obbligato a usarlo. Puoi scegliere liberamente il tuo router.

Ed è proprio qui che entra in gioco OpenWrt.

2. Router con OpenWrt

OpenWrt è un sistema operativo Linux progettato per dispositivi embedded. Invece di offrire un firmware chiuso e statico, mette a disposizione un filesystem completamente scrivibile e un sistema di gestione dei pacchetti. In questo modo non sei più limitato alle applicazioni e alle configurazioni decise dal produttore, ma puoi personalizzare il dispositivo installando il software che preferisci. (OpenWrt GitHub Repo)

In altre parole, OpenWrt è semplicemente un sistema operativo, proprio come Debian, Windows o macOS. I router moderni non sono altro che piccoli computer. Hanno un processore, memoria RAM e memoria di archiviazione. Per molti aspetti sono paragonabili a un Raspberry Pi.

Personalmente preferisco Debian sul mio PC perché mi permette di avere il pieno controllo del sistema. Per lo stesso motivo utilizzo OpenWrt sul router: mi consente di configurare la mia rete domestica esattamente come desidero.

2.1 Qualsiasi router può eseguire OpenWrt?

No. Essendo un sistema operativo, OpenWrt ha bisogno di hardware compatibile. Come qualsiasi computer, anche un router deve avere:

un processore (CPU) che esegue le istruzioni;
memoria RAM per eseguire il sistema operativo;
memoria flash dove conservare il firmware, la configurazione e gli eventuali pacchetti installati.

E, proprio come accade con i PC, l'architettura del processore è fondamentale. Un sistema operativo deve essere compilato per la CPU su cui verrà eseguito.

Ad esempio, non è possibile installare una versione di Debian compilata per processori x86 su un Mac con Apple Silicon, perché appartengono ad architetture completamente diverse. Lo stesso vale per i router. Non tutti i modelli sono compatibili con OpenWrt.

Ed è proprio questo il motivo per cui, poco fa, criticavo la scheda tecnica del gateway TIM. Sapere soltanto che il dispositivo ha tre porte LAN e il Wi-Fi dual band dice ben poco.

Prima di iniziare a configurare un router "intelligente", però, è necessario chiarire un'altra cosa.

Che cosa stiamo realmente configurando? La rete? Il Wi-Fi? Internet? La LAN? La WAN? Che ruolo ha il router? A cosa si collega? E che cosa si collega al router?

La prossima sezione servirà proprio a rispondere a queste domande.

3. Come il tuo ISP ti collega a Internet

WAN è l'acronimo di Wide Area Network. Per semplificare, puoi pensarla come "il resto del mondo", ovvero Internet.

Quando a casa ti colleghi al Wi-Fi, il tuo obiettivo è quasi sempre uno solo: raggiungere Internet senza utilizzare la connessione dati del telefono e, possibilmente, con una copertura e prestazioni migliori.

A fornirti questo accesso è il tuo Internet Service Provider (ISP). Ma in che modo arriva Internet fino a casa? Esistono due possibilità: via cavo oppure via radio.

3.1 Internet senza fili (FWA)

"Wireless" non significa che il router comunica via Wi-Fi direttamente con la sede del tuo operatore. Nel caso della Fixed Wireless Access (FWA), la connessione avviene tramite onde radio trasmesse dalle antenne dell'ISP. A questo punto qualcuno potrebbe chiedersi:

"Quindi è semplicemente Internet mobile?"

In parte sì. Sia la rete mobile sia la FWA utilizzano onde radio, ma hanno scopi diversi. La rete mobile è progettata per dispositivi in movimento, come smartphone e tablet.

La FWA, invece, è pensata per un punto fisso. Sul tetto o sul balcone dell'abitazione viene installata un'antenna orientata verso una specifica stazione radio dell'operatore. Questo permette di ottenere una connessione generalmente più stabile rispetto a quella di uno smartphone, anche se, nella maggior parte dei casi, non raggiunge le prestazioni della fibra ottica. La FWA è particolarmente diffusa nelle aree rurali o dove non è ancora arrivata una rete cablata.

3.2 Internet via cavo

Quando invece la connessione arriva tramite un cavo, le tecnologie più diffuse sono due.

FTTH (Fiber To The Home), cioè fibra ottica fino all'abitazione.
DSL, che utilizza il tradizionale doppino telefonico in rame.

Esiste anche una soluzione intermedia chiamata FTTC (Fiber To The Cabinet). In questo caso la fibra arriva fino all'armadio stradale più vicino, mentre l'ultimo tratto verso casa continua a utilizzare il vecchio doppino telefonico. È interessante notare che la disponibilità della fibra dipende molto dalla posizione geografica.

Può capitare che un edificio sia già raggiunto dalla fibra ottica mentre quello di fronte debba ancora affidarsi alla DSL o alla FWA.

3.3 FTTH: la fibra arriva dentro casa

Quando hai una connessione FTTH, il cavo in fibra ottica entra direttamente nella tua abitazione e termina in un dispositivo chiamato ONT (Optical Network Terminal).

ISP
  │
Fiber
  │
─────────────── Street
  │
Fiber
  │
🏠 Your home
  │
ONT
  │ Ethernet
Router

Se vivi in un condominio, la disponibilità della FTTH dipende dal fatto che l'edificio sia stato collegato oppure no alla rete in fibra. Nel mio caso, fortunatamente, lo era.

4. ONT, modem e router

Quando ho attivato la mia linea Fastweb, il tecnico ha portato la fibra ottica fino al mio appartamento. Una volta terminato il lavoro, mi sono ritrovato con due "scatole". La prima era collegata direttamente al cavo in fibra. La seconda era collegata alla prima tramite un normale cavo Ethernet.

Nel mio caso erano due dispositivi distinti, anche se in molte installazioni possono essere integrati in un unico apparato.

Prima di capire che cosa faccia ciascuno di essi, conviene dare un'occhiata allo schema generale.

Robert Błaszczak: Internet światłowodowy FTTH i ONT Little remark for _ACKCHYUALLY_ readers: comment n 4. is correct for ISP that use DHCP.

4.1 ONT e modem: sono la stessa cosa?

No.

Il primo dispositivo, quello in cui arriva la fibra ottica, è un ONT (Optical Network Terminal). Non è corretto chiamarlo né router né modem, anche se spesso gli operatori usano questi termini in modo piuttosto disinvolto. Un modem prende il proprio nome da MOdulator-DEModulator.

Il suo compito è convertire i dati digitali in un segnale adatto al mezzo trasmissivo utilizzato e compiere l'operazione inversa quando riceve dati. L'ONT svolge un ruolo simile, ma specifico per la fibra ottica.

Converte infatti il segnale luminoso proveniente dalla fibra in normali frame Ethernet, che possono essere gestiti dal router. In altre parole, rappresenta il punto di collegamento tra la rete ottica del tuo operatore e la rete Ethernet di casa.

4.2 Il router

Il secondo dispositivo è il router. Per capire il suo ruolo, immagina di collegare direttamente il cavo Ethernet proveniente dall'ONT al tuo computer.

Se il tuo operatore non richiede ulteriori forme di autenticazione, il computer riceverebbe direttamente un indirizzo IP pubblico e potrebbe navigare su Internet. Ma cosa succederebbe se volessi collegare anche lo smartphone? O la Smart TV? O un altro computer?

Dovresti continuare a scollegare e ricollegare il cavo ogni volta. È esattamente questo il problema che il router risolve. Il router si collega a Internet tramite la porta WAN e crea la tua rete locale (LAN).

Oltre a questo:

assegna indirizzi IP privati ai dispositivi della rete tramite DHCP;
instrada il traffico tra LAN e Internet;
esegue la Network Address Translation (NAT);
protegge la rete locale tramite un firewall;
e, nella maggior parte dei router domestici, fornisce anche la rete Wi-Fi grazie al punto di accesso integrato.

In poche parole, il router è il direttore del traffico della tua rete domestica.

Se invece il tuo operatore ti ha fornito un solo dispositivo — come nel caso dell'offerta TIM vista in precedenza — significa che ONT e router sono integrati nello stesso apparato.

Questo comporta una conseguenza importante. Non puoi semplicemente scollegarlo e sostituirlo con un router qualsiasi.

Hai due possibilità:

utilizzare un gateway che integri anch'esso un ONT compatibile con la tecnologia utilizzata dal tuo operatore;
oppure, molto più comunemente, richiedere un ONT esterno e collegare a quello il tuo router personale.

Ed è proprio qui che torna in gioco la normativa sul Modem Libero. Se l'ONT è integrato nel router fornito dall'operatore, il cliente ha il diritto di richiedere l'installazione di un ONT esterno, così da poter utilizzare liberamente il proprio router.

Considerate le condizioni di scenario tecnologico e di mercato attuale, per le offerte in tecnologia FTTH, è ammessa la restrizione in materia di scelta dell’ONT a condizione che la stessa non sia integrata con il router. Nel caso in cui l’offerta preveda una ONT integrata con il router, deve essere sempre possibile per l’utente richiedere la fornitura e l’installazione di una ONT esterna. In tal caso, la volontà dell’utente di avere una ONT esterna (funzionale alla libera scelta del terminale) dev’essere accertata esplicitamente già in sede di conclusione del contratto. Inoltre, qualora l’utente nel corso dell’esecuzione del contratto decida successivamente di volere usare un proprio apparato, i tempi di installazione dell’ONT esterna dovranno essere tempestivi (segnatamente, entro 5 giorni lavorativi).AGCOM: In caso di servizio fornito con tecnologia FTTH (Fiber To The Home), l’operatore può imporre l’utilizzo di una specifica ONT (Optical Network Termination)?

L'operatore è tenuto a effettuare l'installazione senza ritardi ingiustificati e, secondo le indicazioni di AGCOM, entro cinque giorni lavorativi.

Nello schema precedente ho mostrato come sono collegati tra loro ISP, ONT e router. Ho anche accennato al fatto che è l'ISP ad assegnare un indirizzo IP al router.

Ma come funziona davvero questo meccanismo? La risposta è meno banale di quanto sembri.

Nella prossima parte seguirò i primi istanti di vita del router sulla rete dell'operatore: vedremo come ottiene il suo indirizzo IP tramite DHCP, come funziona il NAT e perché molti utenti oggi si trovano dietro il Carrier-Grade NAT (CGNAT).

OpenWrt: Your Router, Your Rules - Part 0.5: NAT and CGNAT

aL — Fri, 17 Jul 2026 21:40:54 +0000

In the previous article, I covered a different aspect of home Internet networking. I showed, with references to EU regulations, that users have the right to choose the equipment they use to access the Internet instead of being forced to use their ISP's device(s). I also explained which devices are actually needed in a home network and what each of them does.

I still remember that this series is about OpenWrt, and that's exactly where it's heading.

Before getting there, though, there's one important question to answer:

How does a router actually get onto the Internet? What happens the moment an Ethernet cable is plugged into the router's WAN port?

Part 0.5:
 ├ what your ISP can and cannot require
 ├ OpenWrt
 ├ home internet (WAN & Fiber)
 └ ONT vs modem vs router

1. IP address lease

IP addresses can be imagined like mailing addresses, while network traffic, divided into packets, can be imagined like envelopes carrying letters. When you stumbled upon this article, your device actually started communicating with Dev.to's IP address (after Google redirected you here). Every request your browser makes is sent to one of Dev.to's servers, which has its own IP address. While you're reading this article, that communication doesn't stop. Your browser keeps exchanging packets with the server: loading images, checking for new data, fetching comments, and so on.

You can think of this address as the "door" between your home network and the rest of the Internet. It is the address through which you interact with the Internet and through which the Internet can interact with you.

The important thing to understand is that this address has nothing to do with whether you use your ISP's router, a GL.iNet Flint, or any other router. Your public-facing address is assigned by your ISP, not by the router sitting in your home.

NB! In the scope of this article I'll only talk about IPv4 addressing because it still dominates, and, for example, my ISP doesn't give me an IPv6 address at all.

When the ISP's technician gets all the network shaitan machinery working (the ONT, the router, or a single device that combines both), the router contacts the ISP's DHCP server - (in most residential connections) (I'm skipping PPPoE) — and asks to join the network.

1.1 DHCP

DHCP stands for Dynamic Host Configuration Protocol.

Whenever a device connects to a network (client), it needs some information about this network to join it. Most importantly, it needs its own IP address on that network. It also needs to know the address of a router (the default gateway) that can forward traffic to other networks, and usually the address of one or more DNS servers that can translate domain names into IP addresses.

Without DHCP, all of this information would have to be entered manually on every device. DHCP automates the process by assigning an IP address and providing the rest of the network configuration automatically.

DORA process:

Discover – The client: "Is there any DHCP server out there?"
Offer – The DHCP server: "Yes! You can have 192.168.0.4."
Request – the client politely asks: "I'd like to use 192.168.0.4, please."
Acknowledge (ACK) – The server: "Approved. It's yours."

Once the router is connected to the WAN, it broadcasts a DHCP request (DHCPDISCOVER message to locate available DHCP servers). The ISP's DHCP server receives it and assigns the router an IPv4 address.

An IPv4 address is a number like 103.130.238.205, 8.8.8.8, 192.168.1.8, or 10.1.6.7. You can check the address with which you present yourself to the Internet on What is my IP address?.

2. Network address translation

After clicking the link above and seeing an identified address, you may think that it is your own unique personal address, almost like a tax number... BUT! no worries, in all likelihood, it is...:

Shared IP address???

But for the envelopes (data packets) to reach the correct destination, your public (visible on the Internet) IP address has to identify where they should arrive after being requested. You might therefore expect every Internet user to have their own unique public IP address... but nowadays it's very often not the case. ISPs can make thousands of customers share the same public IP address.

WHY and HOW does this network communication not become a complete mess?

WHY: It is because of the scarcity of IPv4 addresses. There are only about 4.3 billion possible IPv4 addresses (2³², since an IPv4 address is made of four 8 bit numbers). That may sound like a lot, but it really isn't. Before we even talk about enterprises, think about households. Nowadays it's completely normal for 2 people living together to own 4 - 6 Internet-connected devices each... Imagine if every single one of them needed its own unique public IP address just to access the Internet, 4.3 billions does not sound that big anymore.

HOW: Network Address Translation (NAT) and Carrier Grade NAT.

NAT literally does what its name says: it translates network addresses. But who performs this translation? Your router. And we are back to the main character of this article.

I mentioned that the router creates Local Area Network. In case of house Wi-Fi this LAN becomes a network of all devices in this house connected to the same network created by router in wired or wireless mode. Inside this network, every device has its own UNIQUE PRIVATE IP address (192.168.x.x, 10.x.x.x, etc.), which cannot be reached directly from the Internet. In most of the cases, router handles the assignment of IP addresses to members of its network with his DHCP server.

Why can't these private addresses be reached directly from the Internet? Because they were explicitly reserved for private networks.

There are 3 private IPv4 address blocks: 10.0.0.0/8 (all 10.x.x.x);
172.16.0.0/12 (all 172.16.0.0 – 172.31.255.255);
192.168.0.0/16 (all 192.168.x.x). If your device has one of these addresses, it is not directly reachable from the public Internet. These addresses are free to reuse in millions of different homes, offices, schools, and companies all over the world because they are only meaningful inside their own local network.

Internet
     |
Public IP: 77.104.200.1
     |
Your Router --> does NAT
     |
-----------------------------
192.168.1.10  PC
192.168.1.20  Phone
192.168.1.30  Some robot

So, if my PC got 192.168.4.17 from the router, how does it reach the Internet?

Whenever a device that is part of the LAN opens a website, the router remembers something like:

laptop: 192.168.4.17:portX
        ↓ sent request to (Persian cats website)
92.113.23.178

and when another device opens another website:

mobile phone:192.168.4.20:portY 
        ↓ sent request to (Parmesan choooeeese)
89.118.107.132

The router also replaces the private source address (192.168.x.x) with its public IP address before sending the packet out to the Internet.

When a reply arrives from 89.118.107.132, the router looks it up in its NAT table and forwards it to the mobile phone. When a reply arrives from 92.113.23.178, it forwards it to the laptop, which happily displays a huge Persian cat picture.

Your router continuously keeps a lil table of these address and port "translations". This is called the **NAT table.

When replies come back, the router knows exactly which device requested them and forwards the packets accordingly. This translation between private and public addresses is called Network Address Translation (NAT).

The important part is that only the router's PUBLIC IP address is visible on the Internet. All devices in your house LAN are identified in Internet by this address. And that public IP address is assigned by ISP.

Now, about CGNAT.

2.1 CGNAT

Carrier Grade NAT (CGNAT) is NAT performed by ISP. Instead of a handful of devices in your home LAN sharing one public IP address, thousands of customers with their dozen of devices can share the same public IP.

The routers of those customers don't receive public IP addresses on their WAN interface. Instead, they receive carrier-private addresses from ranges reserved for that purpose.

ISP keeps track of every connection and makes sure all little packettini travel to the Internet and reach back the correct customer. It acts like a giant traffic controller, making sure replies from the Internet always end up at the right destination.


                   Public IP
               93.44.120.15
                     |
           ISP Carrier-Grade NAT
      ---------------------------------
      |               |               |
  Your router    Alice's router   Bob's router
 192.168.1.x      192.168.0.x      10.0.0.x

Every customer still has their own private home network, but the ISP performs another NAT before packets reach the Internet. So if you are CGNAT-ted by your ISP then when you visit a website, the chain actually looks like this:

Your device (192.168.4.10) 
↓ 
Your router → performs NAT 
↓ 
10.x.x.x (carrier-private address assigned by your ISP) 
↓ 
ISP CGNAT 
↓ 
93.44.120.15 (the public IP address visible on the Internet) 
↓ 
Internet

Your ISP keeps a ginormous translation table that remembers which customer each connection belongs to. That's why everything still works, even though hundreds of people appear to have the same public IP.

Why CGNAT is nasty?

What to care about? For normal browsing, gaming, streaming, YouTube, Discord ... nothing to worry. The problems start when someone on the Internet needs to initiate a connection to you.

For example, suppose you want to host a Minecraft server or SSH into your home PC from your friend house. If you had a stable public IPv4

With a normal public IPv4, you can just simply configure port forwarding on your router.

Internet
     |
93.44.120.15:1234
     |
Your Router (rule: redirect stuff to 192.168.1.50:4321)
     |
192.168.1.50:4321

Anyone connecting in SSH 93.44.120.15:51820 reaches your PC.

With CGNAT, it is impossible. Because there are many other devices sharing same IP. The ISP has no idea where to send arrived requests, because nobody created that connection from inside first. Incoming connections are simply dropped, and port forwarding on your own router becomes useless. Your router never even gets the packets.

But it is not all that hopeless. Most of ISP provide a service for a humble (not really) remuneration of static public IP. Fastweb (my ISP) provides for 3 euros extra per month.

Whether you're using a router with OpenWrt or your ISP's router, NAT works exactly the same way. Understanding it now will make everything that follows - port forwarding, WireGuard, VLANs, and firewall rules - much easier.

OpenWrt: Your Router, Your Rules - Part 0: Your Router = Your Right.

aL — Fri, 17 Jul 2026 19:25:07 +0000

Initially, I planed to write a practical guide on how to configure multiple SSIDs mapped to different VLANs using OpenWrt and LuCI. But then I started diving deeper, and... well, it is what it is (as always). There are just so many concepts that need explaining first. I promise next parts will contain that technical guide.

This part will probably be of interest for readers in the EU, even more so for those in Italy. I'll be referring to the European regulation to briefly discuss how ISPs provision Internet service (center of attention - equipment - router). I'm currently based in Italy, so I'm familiar with some of the Internet service peculiarities here.

There is a lot to worry today about the privacy of our phones, computers, apps, and operating systems. Once one starts becoming curious about privacy, networking, and what actually happens to their Internet traffic, sooner or later attention turns to the device sitting quietly in the corner of the room...

This guide is for people who want to understand and take control of their home network using a router that can run OpenWrt. OpenWrt itself is not really a tool for complete networking beginners. However, it is not as complicated as it may seem. It comes with a user-friendly web interface (LuCI).

If you found this article, chances are you already have an OpenWrt compatible router or are thinking about getting one. Maybe you've picked up bits of networking knowledge over time and are ready to go one step further, but you're still a little unsure where to begin. Or perhaps you're hesitant to change anything because you're worried about breaking something or doing something your Internet Service Provider doesn't allow.

I wrote this guide because I found myself collecting information from dozens of different places and I wanted to put it together in one place.

I also believe Internet Service Providers should provide clear and transparent information about the services and equipment they offer and should never limit customers' freedom to choose their own equipment or switch providers. If they don't, fortunately there is a community that shares knowledge, and I want to contribute to this community.

For my Italian readers, I hope this guide helps you know what to ask and where to look before choosing or changing an Internet provider.

What I will cover in this part:

Part 0:
 ├ what your ISP can and cannot require
 ├ OpenWrt
 ├ home internet (WAN & Fiber)
 └ ONT vs modem vs router

1. Internet Service Providers and EU regulations.

ISP = Internet Service Provider

When someone wants internet access at home instead of relying on mobile data (with its limited data allowance, weaker signal, and often lower or less consistent speeds) they first need to identify Internet Service providers available in their geographical area.

Usually, the choice isn't huge, but having 3 - 5 providers to choose from is fairly common. In general, the larger the city you live in, the more options you're likely to have.

In the European Union, competition is protected by strong antitrust and consumer protection regulations. The goal is to ensure that, when you need a service - in this case, internet access - you have more than one provider to choose from and that companies compete on price, speed, and the features they offer. Not every plan is the same "€27.99/month home internet" package.

1.1 Internet Service as a market's good

From an economic perspective, internet service is a particular "good". Its physical barebone has many characteristics of a natural monopoly, similar to railways, electricity grids, or road infrastructure. Building the underlying physical network is extremely expensive, so duplicating it over and over again is impossible.

NB: Here, by internet service, I mean the infrastructure and service that provide access to the global Internet, the carrier that enables connectivity, not the World Wide Web itself, which consists of websites, applications, and other content ecc.

The internet itself doesn't consist of a single worldwide cable, but the same principle applies to many parts of the infrastructure. Long-distance backbone networks, local fiber deployments, and even wireless infrastructure require enormous investments. Because of that, different Internet Service Providers often share infrastructure or lease access from one another instead of building an entirely separate network. So while competition exists at the service level, the underlying physical infrastructure is often shared, making the market more nuanced and puts customers in a vulnerable and disadvanatgeous position.

1.2 Italian regulations on switching ISP.

In Italy there are 4 bigger "players" on Internet Service Provisioning market: Vodafone, TIM, Fastweb, Wind3.

European competition laws are designed to ensure that you not only have a choice when signing up for internet service, but also that you're free to change providers later without facing unreasonable financial penalties, even if you're using equipment supplied by your ISP.

In Italy, these consumer protections are implemented and enforced by AGCOM - Autorità per le Garanzie nelle Comunicazioni. One of the key principles is that IF/when you want to change electronic communications operator (ISP as example of this operator), termination and migration charges cannot exceed either the customer's average monthly fee or the actual costs incurred by the operator, whichever is lower. Operators also cannot simply demand repayment of every promotional discount they have ever applied; any repayment must be fair and proportionate. This wasn't always the case. Years ago, some ISPs effectively locked customers in by imposing very high exit fees, making switching providers much more difficult than it should have been.

AGCOM on Switching operator and terminating contract

BUT! Not everything is that bright.

users will be able to carry on paying the remaining instalments due for goods and services even if they withdraw from the contract before expiry of the instalment plan, which may not in any case exceed 24 months (Charges for terminating contract)

And here's the interesting part.

What exactly is this "good" that you may keep an EX CUSTOMER paying for up to the next 24 months AFTER TERMINATION OF CONTRACT? Surely not the internet service - the customer just terminated that contract and switched to another ISP. So what remains?

1.3 Home Internet equipment provided by you ISP.

The equipment supplied by the Operator (ISP)! For a typical home customer, this usually means a modem, a router (or a single device that combines both), and a couple of cables.

But wait...

If we're not talking about an enterprise customer or a business with racks full of networking equipment, what kind of expensive equipment are we supposedly paying off for up to 24 months?

And that brings us to the star of this article: the router provided by ISP!

1.4 TIM and their modem for 240 euros bundled with Internet Service offer.

Here are TIM's current home internet offers (as of 10/07/2026):

Access date: 10 July 2026, 07:07 PM [Source](https://www.tim.it/fisso-e-mobile/fibra-e-adsl/fibra-internet-casa)

Clicking on Dettagli costi:

MODEM TIM HUB+ (per tecnologia FTTC), MODEM TIM HUB Pro (per tecnologia FTTH)
€240, payable in 48 monthly installments of €5 each. During the first 24 months after activating the offer, you'll receive a €5/month discount on the modem purchase, reducing the total cost of the device from €240 to €120. (Source accessed 10/07/2026, free translation)

If you terminate the contract before the end of the 48-month period, you will be required to pay the remaining installments for the TIM modem, but only the paid installments, not those covered by the promotional discount. (Source accessed 10/07/2026, free translation).

240 euros for "modem TIM HIB+/PRO". €240 isn't necessarily an unreasonable price for a home gateway (ONT + router actually, yeah to call it modem is wrong and misleading). BUT! The real question is whether the device you're paying for is actually worth €240 - and whether it's the device you want to own.

Hmm... okay... 3 LAN ports, one WAN port, dual-band Wi-Fi...And?

What about the CPU? How much RAM does it have? How much storage? Which Wi-Fi chipset is it using? Does it support OpenWrt? How am I supposed to evaluate whether it's worth €240 with a specification sheet like this?

Would anyone browsing an online store willingly spend €240 on a home gateway described only by the information above?

Probably not. And no one shouldn't.

Not because it's 100% a bad device, it may well be a perfectly capable gateway, but because a customer doesn't have enough information to make an informed decision.

1.5 EU law on freedom to choose your own equipment to use to access the Internet.

European law protects your freedom to choose your own equipment to use to access the Internet. Under Regulation (EU) 2015/2120 on open internet access, ISPs cannot force you to use their equipment as long as your own device complies with the applicable technical requirements.

Key takeaways:

"Operators may not refuse to connect terminal equipment chosen by the user, provided that it complies with applicable national and European regulations."
"They may not impose additional charges, unjustified delays, or discriminate against the quality of the services provided."
"Providers are required to supply adequate information on how to connect to their network and configure the customer's chosen replacement or additional terminal equipment."
"If the operator supplies terminal equipment together with the internet service, it must ensure that the customer is free to choose their own equipment by providing all the necessary technical specifications."
"If the service is provided over FTTH and the ONT is integrated with the router, the user must always be able to request the installation of an external ONT." (source, original in Italian, free translation)

I am not a customer of TIM, and I can't comment on how they handle requests from customers who want to use their own equipment and what happens with that 240 euros gateway bundled with Internet service offer.

My ISP is Fastweb. If I decide to leave Fastweb, my contract states that the migration/termination cost is around €30. Fastweb supplied me by default with a router and a separate ONT. I don't use their router, instead, I use my own router, but I do use the ONT they provided, since that's the device that terminates the fiber connection.

That's a common setup for fiber connections, and in many cases it's exactly what you want.

Now that I have covered the legal side, it is clear that using your own networking equipment is your right. If you are not satisfied with the equipment provided by your Internet Service Provider, you do not have to settle for it.

You are free to use your own router. Routers capable of running OpenWrt are gaining more and more popularity because of the level of customization and control they offer.

2. Router with OpenWrt

OpenWrt is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application (OpenWrt GitHub Repo)

So, OpenWrt is just like Debian, Windows, macOS ecc. Modern routers have a CPU, storage, and RAM. They're basically tiny computers, similar to a Raspberry Pi. OpenWrt is an operating system. Just like I prefer Debian to get the full experience out of my PC, OpenWrt lets me get the full experience out of my router and do advanced network configuration of my house LAN (local area network).

2.1 Any router can run OpenWrt?

If OpenWrt is an operating system, then, just like any other operating system, it needs hardware to run on. That hardware needs a CPU to execute instructions, RAM to run the operating system and applications, and storage to hold the firmware, configuration, and any additional packages you decide to install.

And, just like with PCs, the CPU architecture matters. An operating system must support the processor it runs on. For example, you can't install the Debian on an Apple Silicon Mac because it's built for a completely different CPU architecture.

The same principle applies to routers. Not every router is capable of running OpenWrt. That's why I criticized the specifications of the TIM gateway shown earlier. Listing only the number of ports, Wi-Fi bands tells almost nothing about the hardware inside. Without knowing the CPU, RAM, storage, or chipset, it's impossible to evaluate the device properly, or even determine whether theorically it can run OpenWrt.

Before moving on to the configuration of a smart cool router, it is important to understand what exactly you are able to configure. Network? Wi-Fi? Internet? LAN? WAN? Router plugs where? What connects to router? The next section is about all of it.

3. How ISP connects you to the Internet.

WAN stands for Wide Area Network. For simplicity, think of it as the outside world or "the Internet".

At home, the whole point of connecting to Wi-Fi is usually to reach the WAN without using your mobile data plan and to get better coverage around the house.

An Internet Service Provider (ISP) is the one who gives you access to the WAN. How is that access provided? Either in a wired or wireless way.

Wireless doesn't mean your router connects to your ISP's office via Wi-Fi. Instead, it uses radio signals transmitted by ISP towers. This is called Fixed Wireless Access (FWA). But isn't that just mobile internet? Well, kind of. Both use radio signals, but mobile internet is designed for devices that move around, while FWA is designed for a fixed location. Your house will have an outdoor antenna pointed at a specific ISP tower, which often results in a more stable connection than a phone on a cellular network, but it's not the best. Is FWA common? Mostly in rural or isolated areas where physical cables have not been brought yet.

Speaking of cables, there are two wired ways to deliver Internet:

FTTH - Fiber To The Home OR Fiber To The Node — Fiber To The Node: optical fiber.
DSL - over telephone lines.

And here's the interesting part: you may end up with DSL or FWA even if your neighbors across the street have fiber. Availability is very location-dependent.

If fiber reaches your house/appartment (FTTH), that's generally the best-case scenario. The fiber-optic cable runs all the way into your home (or apartment), where it terminates in an ONT (Optical Network Terminal).

ISP
  │
Fiber
  │
─────────────── Street
  │
Fiber
  │
🏠 Your home
  │
ONT
  │ Ethernet
Router

It is not always like this, it can be that the fiber connection does not reach your home. Instead, it ends at a neighborhood node (a cabinet or distribution point), and the last stretch to your home uses existing copper telephone lines.

If you live in an apartment building, getting fiber Internet depends on whether your building is connected to a fiber network or not. Luckily, mine was.

4. Modem vs. ONT vs. Router

After signing the contract with Fastweb, their technician extended the fiber connection from somewhere in the building to my apartment. Then he had connected it to a box (Box 1). And that box (Box 1) to another box (Box 2). That is my case, but it can be just one box.

I will provide upfront this scheme that shows what these Boxes so and how they are connected. I took a pic from the article on ONT (written in Polish) and slightly modified it and added some comments.

Robert Błaszczak: Internet światłowodowy FTTH i ONT Little remark for _ACKCHYUALLY_ readers: comment n 4. is correct for ISP that use DHCP.

4.1 ONT vs. Modem

That white Box 1 where the fiber cable enters is not the router and cannot router and cannot cretae any home network. It is an ONT (Optical Network Terminal), it is not technically correct to call it modem OR router!

A modem converts digital data into a signal suitable for transmission over a specific physical medium, and vice versa. Modem comes from: MOdulator + DEModulator.

An ONT is not called a modem, but it performs a role analogous to one. Its job is to convert the optical signals traveling through the fiber cable into an electrical Ethernet frames that the router can understand and manage. In other words, it acts as a bridge between the fiber-based network provided by your ISP and your home router.

4.2 Router

Box 2 is exactly the router. To understand its main job, imagine plugging the Ethernet cable coming from the ONT directly into the laptop. Assuming the ISP doesn't require additional authentication, this laptop would receive a public IP address from the ISP, and it would have Internet access. But to connect phone, TV or another laptop, one would have to keep unplugging and reconnecting the cable every time. That's exactly the problem the router solves.

A router connects to the Internet through its WAN interface and creates Local Area Network (LAN). Besides that, it:

assigns private IP addresses to your devices (DHCP),
forwards traffic between your LAN and the Internet,
performs Network Address Translation (NAT),
protects its local network with a firewall,
and, in most consumer routers, provides Wi-Fi through an integrated wireless access point.

In other words, a router is the traffic manager of home network.

If, in your case, your ISP supplied only a single "box" for your fiber connection (forementioned TIM offer), it means that the ONT, the device that converts the optical signal into Ethernet frames is integrated into the router.
In that case, you can't simply replace the device with your own router. You would either need a fully featured gateway that also includes an integrated ONT (or supports the same fiber technology), or,much more commonly,you can ask your ISP to provide a separate external ONT and connect your own router to it.

Again, the "Open Internet (Internet Aperta) and Modem Libero" regulations protect your right to do exactly that.

If the operator supplies an ONT integrated into the router, the user must always have the option to request the supply and installation of an external ONT.
In such cases, the user's intention to use an external ONT (to enable the free choice of terminal equipment) must be explicitly confirmed when the contract is concluded.
Furthermore, if the user later decides to use their own equipment during the course of the contract, the operator must install the external ONT without undue delay, specifically within five working days. AGCOM: In caso di servizio fornito con tecnologia FTTH

As mentioned in the diagram above on how the ONT, router and ISP are connected. I also mentioned that the ISP assigns (leases) an IP address to the router.

The next piece of the puzzle is understanding how IP addressing works de - facto (it isn't as straightforward as it might seem). That will be the topic of the next part of this series, where I will explain IP addressing, NAT, and Carrier Grade NAT (CGNAT), and how they affect your home network.

Building Debian packages from source in bootstrapped Debian

aL — Thu, 17 Apr 2025 15:35:38 +0000

If you’re a curious user - especially one who’s into customizing your Debian - you’ve probably run into this situation at least once: you discover a cool software, but it’s either not available in your Debian’s package repositories, or it is there, but the version is outdated.

Newer versions often bring in completely new features that you actually want to use. When I think of Debian Stable, a few examples come to mind.

Terminal emulator Alacritty, for instance. The version in the Debian Stable repo is dated: Alacritty of this version uses a .yml config file, but newer versions have switched to .toml.

Or btop, the version in Debian Stable doesn’t support NVIDIA GPU monitoring, while the current version does.

And then there's Hyprland, a window manager that’s only available in Debian Unstable and Testing (Trixie). On Debian Stable, it’s not even in the repos at all.

This article is dedicated to a terminal-based file manager yazi that is super mega cool, but it’s not available in any of Debian’s repositories - not in Stable, not in Testing, not even in Unstable.

NB! Building applications from source isn’t necessarily hard in terms of the actual process, but making them work, and more importantly, making sure they don’t break your system, is another story.

Small utility apps that are meant to run in user space (i.e. they don’t touch anything kernel related, like modules, are generally less risky in terms of stability of your Debian afterwards). The main problem is that there’s no guarantee they’ll work properly due to dependencies. The more dependencies an app has, the higher the risk that it won’t work at all.

Also, be very careful when a piece of software wants to downgrade some packages as part of its dependency list. I strongly recommend avoiding that. Downgrading system packages can mess up your system a lot.

Before building anything from source, always evaluate potential security risks. Don’t rush into compiling some random app that has minimal activity on GitHub - especially without reviewing the source code carefully.

NB2! I’m currently using Debian Testing (aka Trixie), which is to become Debian 13, I hope soon. If you’re trying to get Yazi working on Debian Stable, I can’t guarantee it’ll work due to dependency versions.

What’s so particular about building software from source in a debootstrapped Debian, and what does that even mean?

If you’ve ever developed something in Python or used Node.js then this will probably make sense to you. You might be familiar with Python virtual environments, or how Node.js projects usually live in their own directories with all the installed libraries.

When you’re working inside a Python environment and need some libraries, you install them into that isolated environment. Move to another project? Create a new environment, install only what you need, and that’s it. No system-wide Python mess. Same story with Node.js, you usually don’t install JS libraries globally, they just live in the project folder. Clean, contained.

Now, Debian bootstrapping offers a kind of similar idea but in the context of system-level stuff.

Let’s say you want to install Yazi, which is written in Rust. You’ll need Rust installed on your system to build it. Or maybe you want to build Ly display manager, written in Zig—you’ll need to install the Zig compiler. Other programs written in C? You’ll need a C compiler and a bunch of build-time libraries.

But here’s the key point: software often has one set of requirements to build and a completely different set of requirements to run.

For example, with Yazi, you only need Rust to build it. Once that’s done, Rust isn’t required to run the app. So, what do you do? Install Rust, build the thing in 10 minutes, and then… what? Leave Rust on your system? Delete it? What if the software needed tons of other build-time tools that you’ll never use again?

That’s where debootstrap comes in. It lets you create a sort of mini Debian environment:a clean, isolated system within your system. It’s not a full second Debian install, but it is like a mini mirror of your Debian system where you can install/build/test whatever you want without messing up your main OS. It’s like a virtual "project" space for your system-level experiments.

debootstrap is a tool which will install a Debian base system into a subdirectory of another, already installed system. It doesn't require an installation CD, just access to a Debian repository. It can also be installed and run from another operating system, so, for instance, you can use debootstrap to install Debian onto an unused partition from a running Gentoo system. It can also be used to create a rootfs for a machine of a different architecture, which is known as "cross-debootstrapping". (Debian Wiki: Debootstrap)

First, you need to install debootstrap package:

$ sudo apt install debootstrap

Then, I think it is convenient to elevate your user and execute commands as root user ($ changes for # in code snippets, meaning that these commands are run by root user)

First, I create a directory where my bootstrapped Debian will reside:

# mkdir /trixie-chroot
## If you use Debian Stable:
# mkdir /stable-chroot

## And then, I "deboostrap" Debian into this directory
## NB! I use Trixie, and I Debootstrap Trixie!!!

# debootstrap trixie /trixie-chroot http://deb.debian.org/debian/
## If you use Debian Stable:
# debootstrap stable /stable-chroot http://deb.debian.org/debian/

As I mentioned, bootstrapped Debian is not a fully functional system and cannot function outside of the "main" Debian on which it resides. That is due to the fact that it is exactly your main OS sharing with bootstrapped Debian some its components in order to enable a simulation of a complete runtime environment inside the bootstrapped Debian, allowing it to behave like a real system.

This is achieved by mounting pseudo filesystems to bootstrapped Debian, or more correctly, chroot.

chroot on Unix-like operating systems is an operation that changes the apparent root directory for the current running process and its children. (Debain Wiki: chroot)

It may sounds complicated and scary, but actually it is just a couple of commands mount.

First thing to do is to mount the proc filesystem inside the chroot (/trixie-chroot in my case). The proc filesystem provides access to kernel and process information. Many system tools (like ps, top, etc.) rely on /proc to function correctly. Without it tools inside the chroot won’t be able to access process info or kernel parameters.

Second, is to mount the sysfs filesystem to /trixie-chroot. sysfs exposes kernel devices and attributes. It's required by many parts of the system like udev, systemd, etc. Without it hardware-related commands (or anything interacting with kernel devices) may not work inside the chroot.

Third, you need to provide information to chroot Debian about DNS nameservers, especially if you have some custom configuration. Otherwise you will not be able reach internet from chroot and install packages.

All these complex sounding things can be done with 3 commands:

# mount proc /trixie-chroot/proc -t proc
# mount sysfs /trixie-chroot/sys -t sysfs
# cp /etc/hosts /trixie-chroot/etc/hosts

Now, you can "login" into bootstrapped Debian!

# chroot /trixie-chroot /bin/bash

Now, we can start building Yazi from source! I’ll be following the official installation guide...
...with one interesting modification you might find useful for other Rust-native apps.

But let’s get started.

First, it's important to note that Yazi has various dependencies: because as a terminal file manager, it can do things like preview images and different file types right inside the terminal! And of course, this kind of functionality requires some additional software to be installed.

For me, the dependencies of Yazi looked pretty familiar. You can check them one by one if you’re unsure.
So why am I installing them into a Debian chroot if I don't actually plan to use it?
Well, I'm not that advanced when it comes to Rust apps. I’ve got more experience building from source using make, and if you’ve ever done that, you probably know about the ./configure step—it scans your system and sets the right parameters for the build.

What often happens is, if something’s missing on your system, that is not required by any core feature of to be built software, these features are just get skipped during build processes, because requirements for them are not satisfied. I’m not sure if Rust works exactly the same way, but either way, it’s not a big deal: I’m planning to destroy this chroot after installation anyway.

chroot # apt update
chroot # apt install ffmpeg 7zip jq poppler-utils fd-find ripgrep fzf zoxide imagemagick

Here comes NB for Debian Stable users:

Note that these dependencies are quite old on some Debian/Ubuntu versions and may cause Yazi to malfunction. In that case, you will need to manually build them from the latest source. (Yazi Installation guide)

As the next step, I need to install Rust, of course:

chroot # apt install curl
chroot # curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
chroot # rustup update

And after this... I diverge from the official installation guide. Actually, this project is awesome, and installing it is super easy—to the point that it will literally leave only Rust installed on your system afterwards. Here's the command from the installation guide -
cargo install --locked yazi-fm yazi-cli. As you can see, this installs two packages directly on your system.

However, in my chroot setup, this is kind of useless, because if I run that command, it’ll install those packages inside the chrooted Debian, which I obviously won’t be using.

But here’s the cool part: Rust has this amazing crate called cargo-deb.

Debian packages from Cargo projects
This is a Cargo helper command which automatically creates binary Debian packages (.deb) from Cargo projects. (Rust Docs: cargo-deb)

Now you can probably guess what my goal is : I want to get two .deb files: one for yazi-fm and one for yazi-cli. Then I can just copy them over to my main system and install them with dpkg. Simple and clean!

To do that, first I need to install cargo-deb from crates.io.

chroot # rustup update  
chroot # apt install build-essentials # gcc compiler
chroot # cargo install cargo-deb

After this, I clone the Yazi project's GitHub repo:

chroot # git clone https://github.com/sxyazi/yazi.git
chroot # cd yazi

And then ... I just instruct Rust to build from source 2 .deb files:

chroot # cargo deb -p yazi-fm --locked
chroot # cargo deb -p yazi-cli --locked

After these two process are completed 2 .deb files are placed into ./target/debian directory of yazi root directory.

What is left is to copy these two files to the main system and install 2 packages from them using dpkg.

chroot # exit
# exit 
$ cd # teleporting to home directory of my regular user
$ sudo cp /trixie-chroot/root/yazi/target/debian/yazi-cli_25.4.8-1_amd64.deb .
$ sudo cp /trixie-chroot/root/yazi/target/debian/yazi-fm_25.4.8-1_amd64.deb .

$ sudo dpkg -i yazi-fm_25.4.8-1_amd64.deb
$ sudo dpkg -i yazi-cli_25.4.8-1_amd64.deb

Voila!

Command to launch Yazi File manager: yazi
Command to launch Yazi CLI: ya

Where to Start in Web Development: Ignoring Learning HTTP(S), URLs, DNS, IP, SSL Will Have Consequences...

aL — Fri, 21 Mar 2025 18:49:50 +0000

This is the second article in a series on Web Development. If you’re just starting out, I highly recommend reading the first part first. In that part I illustrated and explained the DOM (Document Object Model); in this article, I’ll use the term DOM assuming you’re already familiar with it.

This isn’t my first article on networking. From my profile stats, I’ve noticed that topics around networking get few readers, so I can guess that now you might be thinking, "I can skip this for now—I don’t really need it for starting with web dev". Well, here’s what I believe might happen on your web development learning path if you postpone learning the things listed in the title:

CRUD Applications, the Database part will be pretty tough.

Improper database client configuration, struggle with setting up secure connections and handling data flows properly.
HTML Forms & HTTP methods mess-ups

Sensitive data unintentionally spawning in URL because of GET method in form tag? Plus, in general, handling user inputs may be confusing.
Try/Catch Blocks in JS fetch functions

When you fetch data using JS, you’re dealing with network requests and responses. If you do not understand how those work, you will be confused by what you’re actually catching in an error.
Debugging fetching functions

Without understanding HTTP language or the request-response cycle, you will spend extra time trying to understand why your frontend does not display what it should. Let's not mention the situationships when some try to fetch something from remote servers pointing to the localhost.
Hosting your web apps (portfolio, pet projects, etc.)

Eventually, you’ll want to put your work online. Without networking fundamentals, you might not know even where to start.
Routing in your web apps

If you don’t understand how URLs translate into requests and how servers respond, you might struggle with design of your app's routing schemes.
APIs

Web development revolves around APIs. APIs are mostly about communication via network.
Dockerizing your apps

I noticed the urge to containerize anything that is not yet containerized even on early stages of development, but containerization involves such things as port mappings, virtual networking etc. You might also struggle with linking containers together or exposing your app's parts properly.

I hope I have convinced you somehow to invest your time in learning networking fundamentals.

In the previous part’s conclusion, I showed this scheme visualizing on high level how browsers work:

As you can see in that diagram, the "query" from the browser’s address bar plays a key role: by using that "query", your browser’s networking layer sends a request and receives a response from the correct server. That response contains some data (for example, .html, .css, and .js files) that gets rendered—based on these files the Document Object Model is constructed by the browser—and then visualized.

In this article, I’ll focus on what’s happening in the browser’s networking layer and also explain what servers are and what role they play (Spoiler: "server" is not always about a backend!).

Here is the roadmap:

Browser's Address Bar
URIs and URLs
HTTP Protocol
1. Internet Protocol and IP addresses
2. Transmission Control Protocol (TCP)
3. TCP/HTTP Network traffic
4. Understanding Ports
5. DNS
6. TCP in action: 3-way handshake
HTTPS
1. Little extra info: multiple IP addresses and horizontal scaling of web apps
2. About encryption
3. TLS/SSL certificates
4. Secure communication channel

1. Browser's Address Bar

Modern browsers are quite powerful, and you might not even notice that when you type something in the address bar, you’re effectively using it like a search engine (default search engine of your browser). You can drop in any text, and the browser takes that text and forwards it to your default search engine—all without you really realizing.

But if you’ve been using browsers and the internet for a long time, you might remember it wasn’t always like this. You couldn’t just throw any random text into the address bar and expect the browser to figure it out. Back then, you had to first go to the search engine’s website (e.g., Google or Bing) and then type your search query there.

For demonstration purposes, I’ll use a silly "query". My browser is Brave, and its default search engine is Brave Search. I type this into the address bar: difference between .com and .dev. This is what I see:

What if I type the same "query" without spaces, and even worse, with dots between words - difference.between.comand.dev? It can happen—maybe you’ve done it when typing quickly on your phone and missed the spaces. Such "query" results in:

Error example: DNS address could not be resolved

Jump back to DNS section

So here comes the error: the browser definitely did not process both queries the same way. The first query was treated as a string that got passed to the search engine, but the second query (with dots) made the browser do something else instead of just processing it along as a search query.

If I double-click on the address bar in both cases, here’s what I see:

https://differencebetween.com.and.dev/ — which leads to an error page
https://search.brave.com/search?q=difference+between+.com+and+.dev&source=desktop&summary=1&conversation=1dd960092fc9678fb88e64

Those are the "queries" the browser processed. I keep putting "query" in quotes (" ") because the technically correct term is a URI, and the actual "query" part is:
?q=difference+between+.com+and+.dev&source=desktop&summary=1&conversation=1dd960092fc9678fb88e64. That’s part of what I typed into the browser’s address bar. Let’s start with what a URI is.

2. URIs and URLs

Uniform Resource Identifiers (URI) are used to identify "resources" on the web. URIs are commonly used as targets of HTTP requests, in which case the URI represents a location for a physical resource, such as a document, a photo, binary data.
The most common type of URI is a Uniform Resource Locator (URL), which is known as the web address.
A Uniform Resource Name (URN) is a URI that identifies a resource by name in a particular namespace. (MDN web docs: URIs)

A URL (Uniform Resource Locator) is renown term not only by developers but also by just users. The point is that a URL ∈ URI (is a subset of), meaning a URI is broader (every URL is a URI, but not every URI is a URL). A URL is a specific type of URI that not only identifies a resource but also provides the information needed to retrieve it (such as its network location and protocol).

In the previous article, I gave examples of opening files from my PC using this URI:

file:///home/lalala/Projects/DEVTO/webdev/randomPDF.pdf

This is a URI, but not exactly a URL—it’s a bit ambiguous because it could be called a URL if you consider it a locator for a file resource. However, it is common to use “file URI” to emphasize that it accesses a local file rather than a resource over HTTP/HTTPS.

By contrast,

https://search.brave.com/search?q=difference+between+.com+and+.dev&source=desktop&summary=1&conversation=1dd960092fc9678fb88e64

is definitely both a URI and a URL.

First, I want to "decompose" one illustrative URL - http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument to demonstrate all its functional parts, which can help in understanding how it works—this is a key moment:

_1. http:// is the scheme of the URL, indicating which protocol the browser must use

www.example.com is the host name of the URI, indicating which Web server is being requested. Here, we use a domain name. It is also possible to directly use an IP address, but because it is less convenient, it is rare to do so, unless the server doesn't have a registered domain name

:80 is the port of the URL, indicating the technical "gate" used to access the resources on the web server. It is usually omitted if the web server uses the standard ports of the HTTP protocol (80 for HTTP and 443 for HTTPS) to grant access to its resources. Otherwise, it is mandatory.

/path/to/myfile.html is the path of the URL, indicating the location of the resource on the web server. In the early days of the Web, this was an actual directory path to a physical location on the web server. Nowadays, web servers usually abstract this to an arbitrary location.

?key1=value1&key2=value2 is the query of the URL, which are extra parameters provided to the web server. The parameters are a list of key/value pairs prefixed by the ? symbol, and separated with the & symbol. These can be used to provide additional context about the resource being requested._

Let's detangle it all one by one. I'm starting with the protocol.

In a URL, anything before :// is a protocol. When I was opening local files from my PC, I used the file:// protocol to access them. However, the most common and widespread protocol—and the one you'll 100% be dealing with—is HTTP(S). So it makes sense to explain it.

3. HTTP Protocol

HTTP: Hypertext Transfer Protocol (HTTP) is an application protocol that defines a language for clients and servers to speak to each other. This is like the language you use to order your goods. (MDN web docs: How the web works)

The browser acts a client, and it communicates with servers using the HTTP language (If it is indicated in the URL, i.e. when it starts with http(s)://). This language per se is a language of verbs—actions with self-explanatory names like GET, PUT, DELETE, POST, TRACE, and others. The browser sends one of these verbs to an address indicated in the URL (URL addresses I will cover later), and if that address is "valid", the server found on this address sends a response.

I want to clarify that, in this article, a server is simply a computational device—like the PC or notebook you’re using, but without a monitor or GUI. For simplicity, just think of it that way for now.

When (if) the server responds to the browser’s request, it does so using HTTP, as it was contacted via this protocol. If the request sent by browser got rejected by server for any reason, HTTP ensures that a client (browser) anyway receives a response. That’s very important (for your JS try catch blocks :D). HTTP responses are more complex than requests (verbs) — the status codes are a crucial part of any HTTP response.

_HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:

Informational responses (100 – 199)

Successful responses (200 – 299)

Redirection messages (300 – 399)

Client error responses (400 – 499)

Server error responses (500 – 599) (MDN web docs: URIs)_

Now, let me show you some nerd fun that will help you to understand in deep how HTTP protocol works. Of course you can learn all the status codes, methods of HTTP language, but I think it is not enough if HTTP protocol remains a block box for you, especially when it comes to the debugging of your web apps.

The difficulty in understanding networking concepts is because it's kinda all happening under the hood – you don't see any of the communication statuses or responses in the raw format, until you get an error. This is true if you're a user; but if you're a dev, you will be intact even more with networking stuff. However, even if you're a dev and were avoiding networking by all means, I'll show you what's inside this black box.

Let's start with the fact that the HTTP protocol sits on top of another protocol, TCP.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network (Wikipedia:TCP)

Here is the chain of protocols:

HTTP Protocol <-- TCP Protocol <-- IP Protocol

Let's start from the bottom up.

3.1 Internet Protocol and IP addresses

IP (Internet Protocol) has the task of delivering packets from the source host to the destination host solely based on the IP addresses in the packet headers. For this purpose, IP defines packet structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information (Wikipedia:IP).

IP may be quite familiar to you, especially when it comes to the term "IP address". The device from which you're reading this article has an IP address, and my PC, from which I'm writing this article, also has an IP address. DEV.TO, as a portal, has an IP address as well. Even though your device and my PC do not communicate directly, both our devices are communicating with DEV.TO.

There are actually two versions of the IP protocol: IPv4 and IPv6. As stated in the Wikipedia quote above, the IP protocol is about communication between the source and destination.

Try to think of packets of data as envelopes with some info—Internet Protocol is mostly about the structure of addresses. Each envelope with a letter (data) inside has a to (destination) and a from (source).

Now, what about IP versions? Let's say that we lived in the old days when people resided in houses rather than apartments (one house=one household). The addressing system was quite different—just the street name, house number, city, and country. That system worked fine. But then, as time went on, globalization and urbanization began, and more people started living in cities. It can't be that only one family lives in a huge house, so houses started to be divided into apartments (one house=many households). Now, if a letter arrives with just the street, city, country, and house number, it will not find the correct Destinee. A new "addressing" mechanism had to be invented.

Image source

That's exactly what happened with IPv4 (Internet Protocol version 4). It was created when the Internet was a far less "global"—few had access to it—and it worked fine. But look at us in 2025: each of us usually has at least two devices that need to be connected to the Internet, and many of us don't live alone but with family, so the numbers multiply. Here’s the thing: IPv4 addresses are mathematically limited—the number of unique addresses available is around 4 billion. If you calculate only for private use and individuals, it is misleading because think also about all big companies with many servers that use unique IP addresses if they're connected to the global Internet.

So, a newer version of IP was born—IPv6 (Internet Protocol version 6). This version of the protocol completely changes the address structure and syntax, providing an enormous pool of unique addresses so that every server, every personal device can have its own unique address.

The problem is that IPv6 has not yet been widely adopted, and most of the Internet is still on IPv4.

So you may think there's a problem: network packets (the envelopes from the analogy above) are getting lost, because the addresses are "duplicated"... but that's not true. Various mechanisms somehow solve the issue of IPv4 addresses scarcity, and the core mechanism is NAT—Network Address Translation. I won't go into detail here, but if you genuinely want to advance your understandings in networking, you can read my other articles on networking: this, and this.

In the scope of this article, I just want to explain the key point of how NAT affects your devices and any web app you will ever develop and host. Your devices don't have unique IPv4 addresses when connecting to the internet. Firstly, you never connect directly to the internet from your devices unless you have a device directly attached to a fiber cable connected in a wired way to the global net. Yes, if you think the global internet is wireless, you're mistaken. The global internet is entirely wired, except for the internet provided by satellites. So, how do you access the internet from your devices? Mostly wirelessly, I imagine—you connect to a Wi-Fi router. And if you've ever handled internet provision at your home, you might have seen the operator arrive at your house with a thin cable, your to be Wi-Fi router and connecting it with a wire! Another alternative is using a SIM card in your router or mobile phone, which receives signals "wirelessly".

While cellular towers broadcast wireless signals to phones, themselves they rely on a wired or high-capacity link to connect to the rest of the carrier’s network. In the case of Wi-Fi routers, fiber cable is physically brought to your internet provider's establishment, which is connected by cable—first to the city, then to the country, and then to the rest of the world.

Anyway, that was just FYI. What's important for web development is this: at your home setup your Wi-Fi router has a unique IPv4 address*. (* stands for the fact that first, most probably, this unique ipv4 address is not as long lasting as the classical physical address of a building - it is constantly changing - usually much more than once a day; second, there is such a thing as CGNAT and I leave it for you to check what is it). Your devices connected to Wi-Fi router don't have unique IPv4 addresses each. If you check your PC's IP address, you'll see something like 192.168.x.x.

I see this this:
(If you're on Mac or Windows, check the web on how to find your IP address information.)

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 ....
    ...
    inet 127.0.0.1/8 scope host lo
    ...
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    ...
    inet 192.168.8.9/24 brd 192.168.8.255 
    ...

There are two things you see in my output: lo and eno1: 192.168.8.9

eno1 is the network interface—or the point of connection for my PC. It's the Ethernet cable connected to my Wi-Fi router, and that's its address. What is lo? It's the loopback interface. You probably know it well—it's the famous localhost - 127.0.0.1.

My Wi-Fi router has a public IPv4 address. Also, it is creating a local network (my home network; LAN - local area network) that spans as long as the signals of my router reach. Any device that can connect to my Wi-Fi router becomes a part of this network. This network is a default private network, and it uses IP addresses reserved for private usage. So, my PC has the IPv4 address 192.168.8.9, my phone - 192.168.8.10, my laptop - 192.168.8.5 and so on. This default local network can accommodate up to 254 devices simultaneously connected to my router. With the NAT mechanism, my Wi-Fi router translates all the requests and -responses sent to global net from each device connected to it, granting them access to the internet (e.g request: I go to google from my PC to find a picture of kitty and then I download it).

So, how is this all related to web dev?

You cannot directly host anything you develop on a private IP address if you want to expose it to the global net.
Anything!!! Absolutely anything you see on the web—any page you manage to open, any existing services, anything at all—resides/is stored on a "device" with an IP address.
Whatever you visit on the web from a browser: A. exposes your external (e.g the router’s public IP) IP address (little remark: VPNs and proxies can mask your IP :-)) B. exposes its IP address to your browser.
The alfa-numerical part following http(s):// in a URL (roughly speaking, "the name" of a website) can be presented as an IP - e.g you can generally replace http(s)://example.com with http(s)://<ip_address> and access the site that way, however, some sites have domain-specific configurations, so entering an IP might not always load the intended site, but the point is that a domain name ultimately resolves to an IP (on domains later on!!).

Okay, basta with IP. I introduced key information about IP addresses:

Next up: TCP.

3.2 Transmission Control Protocol (TCP)

In my analogy with envelopes and letters, the Transmission Control Protocol plays the role of a delivery service. Thanks to IP, envelopes (network packets with data) have a standardized addressing system, so if they're delivered responsibly, the data will arrive from sender to recipient. This is where TCP comes into picture: its job is to deliver envelopes (network packets with data) in a reliable way, ensuring they reach their destination.

TCP isn’t the only protocol on top of IP. There’s also UDP (User Datagram Protocol), but I’ll leave it aside for now. This meme fits well to explain the difference:

Anyway, since HTTP sits on top of TCP, let’s concentrate on TCP rather than on other protocols.

To illustrate TCP in action, as well as HTTP and HTTPS, I’ll share the results of some network packets capturing. By the way, continuing my envelope analogy: the HTTP protocol is like the language of the letter (data) inside the envelope (network packets). The sender writes the letter in a language, and the recipient responds in the same language.

When a letter (data) is sent in the HTTP "language", anyone nosy who intercepts the envelope can open it and read the letter (data) clearly, because it’s not encrypted. But if the letter (data) is written in HTTPS "language", this nosy someone will only see some general information and then abracadabra instead of the actual content.

HTTPS is a secure version of HTTP that stops bad people from reading your data while it is being transported. On the modern web, pretty much every server uses HTTPS, so if you don't include it explicitly, the browser assumes that is what you are using and adds it for you.

Anyway, I promised some nerd fun, and by that, I mean that I will capture network packets that travelling in and out of my PC to show you what is inside.

3.3 TCP/HTTP Network traffic

For HTTP network traffic, I’ll use this site: http://httpforever.com/.

For HTTPS traffic, I’ll use the URL of my DEV.TO profile as an example: https://dev.to/dev-charodeyka.

The tool I’ll use to capture network packets is Wireshark (it has a GUI). I could do the same with tcpdump, but for demonstration purposes, I want something visual.

I’ll also be using a software called curl:

curl - transfer a URL
curl is a tool for transferring data from or to a server. It supports HTTP and HTTPS protocols.

In this setup, curl will act as the client in the typical client–server relationship. In web dev a browser is usually the client in such a setup. The command I’ll use is curl with a verbosity flag (-v), so I can show you all the details.

Curl output

$ curl -v http://httpforever.com/
* Host httpforever.com:80 was resolved.
* IPv6: 2604:a880:4:1d0::1f1:2000
* IPv4: 146.190.62.39
*   Trying [2604:a880:4:1d0::1f1:2000]:80...
* Immediate connect fail for 2604:a880:4:1d0::1f1:2000: Network is unreachable
*   Trying 146.190.62.39:80...
* Connected to httpforever.com (146.190.62.39) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: httpforever.com
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Mon, 17 Mar 2025 21:00:08 GMT
< Content-Type: text/html
< Content-Length: 5124
< Connection: keep-alive
< Referrer-Policy: strict-origin-when-cross-origin
< X-Content-Type-Options: nosniff
...
<
<!DOCTYPE HTML>
<html>
    <head>
        ....
</html>

Back to explanation

Hear me out! What you’re seeing is exactly the same thing that happens under the hood when I visit this website from my browser. It might be confusing—like, how can the website (the "front end") also be about servers?

Well, that confusion arises because there’s a common understanding that "frontend" refers to something to be run in a browser (client-facing), and "backend" is the stuff on servers. But actually... everything runs on servers. Hard-to-swallow pill: if you want to self-host your future web apps and avoid paying for web hosting or PaaS, welcome to servers and the Linux world.

The backend and frontend parts of a web app can reside on the same physical machine (or the same cloud instance). However, on the software level, they are separated. Frontend is running on web servers (software, "server" comes from the fact that this software is serving something).

This line from curl output shows which web server the http://httpforever.com/’s frontend is running on:

< Server: nginx/1.18.0 (Ubuntu)

The physical server has Ubuntu OS and is running the Nginx. Physical server's IP is:

* IPv4: 146.190.62.39
default HTTP port is 80 so we see this:
*   Trying 146.190.62.39:80...

3.4 Understanding Ports

Now, about ports (:80), even if it’s outside the main scope of this article, I’ll explain with an analogy so you understand what a port is.

Imagine you have a house. To enter, you have a door. If you remove the door, you can’t enter the house. If you don’t know where the door is, you also can’t get in. Let’s expand on that: maybe you have a door for you and your family, a little door for your cat, and a big door on the ground floor for your car. If you try to drive your car through the cat door, it won’t work, and if the cat goes through the garage door, it ends up somewhere it doesn’t need to be.

It’s the same concept with ports. HTTPS traffic uses port 443, and HTTP uses port 80 by default. You may face the need to open other ports on your PC/server, as many services have their own default ports—like databases. All these ports need to be open if you want external access for a given service. And it’s also about what requests or messages you’re pushing through a port. Returning to my analogy: the cat enters the house through its little door looking for food. If it walked into the garage, it wouldn’t find its feeder. Same idea with software. For example, Mongo DataBase’s default port is 27017. If you try to send curl requests there expecting an HTTP response, it won’t work, because MongoDB can’t respond in that way.

Before I move on to the same command for an HTTPS site, I want to explain the first line of the curl output:

Host httpforever.com:80 was resolved.

3.5 DNS

You can have a look again on the error that I encountered when I dropped in the browser's search bar an erroneous URL: https://differencebetween.com.and.dev/ DNS error

Basically, the browser displayed an error because I was trying to reach an abracadabra web address, differencebetween.com.and.dev, using the https protocol. The browser couldn’t find a server at that "address" because it simply doesn’t exist. But how did the browser figure that out? Where did the browser "look up" that "address"? Does your browser have some kind of "address book" containing all the existing "addresses" on the web? Of course not. Every browser indeed checks an "address book" of the entire Internet, but it does so via the network – it doesn’t store it locally.

Before I give a name to this "address book of the Internet", I want to explain what is in this book, gracefully connecting all the pieces of information I shared above. However, I guess you can already guess what a browser needs to find a server... an IP address, of course! Take another look at the curl output:

* Host httpforever.com:80 was resolved.
* IPv6: 2604:a880:4:1d0::1f1:2000
* IPv4: 146.190.62.39
*   Trying [2604:a880:4:1d0::1f1:2000]:80...
* Immediate connect fail for 2604:a880:4:1d0::1f1:2000: Network is unreachable
*   Trying 146.190.62.39:80...
* Connected to httpforever.com (146.190.62.39) port 80

First thing that happened after curl request was sent to http://httpforever.com was that this web address was resolved. Resolved de-facto means that the client (curl in this case, though the same is completely true for browsers) received the information that httpforever.com == 146.190.62.39 (IPv4) and httpforever.com == 2604:a880:4:1d0::1f1:2000 (IPv6). The browser immediately tried to send the HTTP request to the first IP it found, which was the IPv6 address. But as I mentioned, the Internet and many servers are still only on IPv4, so the connection failed... then it quickly started to send the request to the IPv4 address, and the connection was successful!

So, where do browsers get a "dictionary" that maps human-readable addresses to IP addresses? Browsers get it from DNS (Domain Name System).

The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through domain names, like nytimes.com or espn.com. Web browsers interact through Internet Protocol (IP) addresses. DNS translates domain names to IP addresses so browsers can load Internet resources. (Cloudflare: What is DNS?)

I won’t go into too much detail on DNS, it is simple per se in what it is for, but it is not that simple to configure from the standpoint of networking configuration. Here is the schematic representation on how your browser reaches Domain Name System:

URL example: https://www.cloudflare.com/learning/dns/what-is-dns/
[Browser] --> (Browser's internal DNS cache)
                    |
                    v
        Found IP of www.cloudflare.com?
        |                |
        No               Yes ---> resolved, sending request...
        |
        v
[Operating System of PC/server] --> (Local DNS cache & configuration)
                    |
                    v
        Found IP of www.cloudflare.com?
        |                |
        No               Yes ---> resolved, sending request...
        |
        v
[Router/Modem] -->Forwards DNS query
               Forwards where? Depends on configuration..
                │             OR               |
                v                              v
  [  External Public DNS           [Internet Service Provider's 
   (e.g. Google, 8.8.8.8)]                 (ISP) DNS] 
                |             OR               |
                v                              v
               Found IP of www.cloudflare.com?
                |                |
                No               Yes ---> resolved, sending request...
                |
                v
         www.cloudflare.com does not exists.

The key takeaway is that a "human" address in a URL is just for people. Underneath, there’s always an IP address. And as a first step, browsers try to look up the "translation" of the provided address into an IP. If it fails, that’s the end of the query and results in an unavoidable error. Another takeaway is that you can't, just out of the blue, decide that your server with IP 123.124.135.5 (for example) will have a domain name like coolest-site.eu by specifying it in your server’s configurations. I hope that’s pretty obvious.

3.6 TCP in action: 3-way handshake

Anyway, here is the nerd fun!!! Haha, I called it nerd fun because once my colleague told me that I need to have a social life after I mentioned that I observed my home lab's network packets for hours to examine a peculiar network anomaly.

As I mentioned, I use Wireshark for monitoring network traffic on my PC and with this tool I can capture all the network packets that pass through it. If I start capturing everything, the output gets flooded in seconds, because any website I open in my browser ends up in the stats table. Currently, I have my PC connected to only one network, and I will capture packets traveling via this network. I will filter out only the packets for HTTP example site, http://httpforever.com, as I already know the IP after the first launch of curl I can use this network packets filter: ip.addr==146.190.62.39 and tcp.port==80. So I start capturing with an active packet filter in Wireshark, and then I just open http://httpforever.com in my browser.

Here is what I see:

That’s just what happened under the hood for one simple action: I tried to load the landing page of http://httpforever.com.

Let’s decompose it. First, for each network packet (each row in the table above = network packet) there’s the source and destination. The source of the first packet is the private IP address of my PC, as the communication was started by my PC (specifically, by my browser). The destination of the first network packet is the IP of the site http://httpforever.com. In the Info column, as a first thing you see the ports 40500 → 80. Yes, 40500 is the port used on my PC during this communication - it’s an ephemeral port, which is basically a byproduct of NAT applied by my router. The first thing after ports in the first row, column Info (No. 7) you see is the abbreviature SYN — SYN (Synchronize) is the first step in making a handshake, so it’s like extending your hand to someone else to initiate a handshake.

Next, the server where http://httpforever.com's frontend runs, sees the handshake request from my browser and acknowledges it, which is the 2nd step of handshake - SYN-ACK (Synchronize-Acknowledge) (No. 8 line in the table above).

Next, my browser sends an ACK to confirm the server’s SYN-ACK, and that completes the handshake (No. 9 line in the table above). At this point, a reliable connection is established, and data transmission can begin.

As you can see, the row No. 10 in the table informs that the network packet with HTTP GET method request was sent - data exchange between my browser and the server of http://httpforever.com has started -after the handshake, my browser immediately requests what it needs. The server acknowledges the GET request and starts sending data (PSH) (rows No. 11 - 13 in the table above).

Notice there are more than one transfers of different lengths before the line No.18 that contains HTTP response 200 - OK, meaning, that first GET request from my browser was completed. That is because, servers servers over HTTP never send everything requested in one big mega data transfer. For example, if you wanted to download a 10 GB video, the website's server from which you are downloading it wouldn’t just dump the entire file at once—that would overwhelm your network connection. Instead, HTTP network packets are chunked, and the full content is split across those packets. How the data is spitted in network packets by size, is there some rule? There are limits on the server side and on your PC. In fact, without realizing it, you’ve already seen your PC’s limit per network packet if you connect your PC to the Internet via ethernet cable - by default it is 1500 bytes, and this value is called MTU - Maximum Transmission unit. Here is the recap of $ ip a command, output of which contains mtu value:

$ ip a
...
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    ...
    inet 192.168.8.249/24 brd 192.168.8.255 
    ...

Some packets can for some reasons not arrive to client from the first attempt, however, TCP will do its best to ensure the delivery of everything, that's why it is considered as a reliable protocol. And that is why I called it in my analogy with envelopes and letters as a delivery service. 3 way handshakes, and reattempting of sending network packets if something goes wrong.

Image source; this picture is used to stress out the fact that TCP acts as a "reliable delivery service" for network packets - not just dropping them "by the door", but requiring the "signature" as a confirmation of delivery

NB! the Wireshark output may be a bit not accurate for visualizing how network packets are split up due to the fact that Wireshark takes data segments and reassembles them into the complete application-level message. However, I wanted to demonstrate that network traffic is more complex that it seems and it is segmented.

However, this is very important to know that data travels in chunks when requested—and never gets dumped all in one bulk. It is key for cases when you have to fetch/process huge amounts of data with your JavaScript/TypeScript code (for example, NDJSON). You can take advantage of streaming approaches instead of fetching an entire file at once without streaming and nuking your PC's RAM while trying to process it. Plus, all the "download status bars" are exactly about tracking the chunks of data that arrive and comparing how much is left to the total size of the data being downloaded.

So, I showed you nerd fun with HTTP network traffic - to help you understand how HTTP works, and what happens when you try to open a website from your browser. Now, what's left to discuss is HTTPS.

4. HTTPS

If you look again at the output of a request sent by curl to website via HTTP, the most important part is the last section (which I horribly shortened), but here is the point: after all the info about HTTP communication, there’s actual data in HTML format - all the elements that will be displayed in your browser after it will reconstruct and render DOM based on this html data.

Also, if you look at line No.18 in the Wireshark table from above, you can see that the content type sent over as HTML to my browser was (text/html).

Using Wireshark, I can actually follow each network packet. So, if I select the packet that was carrying the data, I can investigate it—and I see the content in plain text. Here it is:

Getting ahead, here’s what I see if I capture network traffic for an HTTPS site: in Wireshark, I start tracking TCP port 443 and the IP of the DEV.TO website, start capturing packets, go to https://dev.to/dev-charodeyka in my browser, identify any packet with data in Wireshark table, and put my nose there, trying to see the data:

Abracadabra! The real content, html data is hidden. In the process of transfer, data transferred via HTTPS—and not HTTP—is encrypted. So if someone tries to capture it and sniff the content, they won’t understand what it is.

How is that possible? I’ll demonstrate by repeating the same procedure I did for the HTTP website—I’ll send a curl to the HTTPS site - https://dev.to/dev-charodeyka.

$ curl -v https://dev.to/dev-charodeyka
0* Host dev.to:443 was resolved.
* IPv6: (none)
* IPv4: 151.101.66.217, 151.101.2.217, 151.101.194.217, 151.101.130.217
0*   Trying 151.101.66.217:443...
* GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
* ALPN: curl offers h2,http/1.1
* found 152 certificates in /etc/ssl/certs/ca-certificates.crt
* found 456 certificates in /etc/ssl/certs
* SSL connection using TLS1.2 / ECDHE_RSA_CHACHA20_POLY1305
*   server certificate verification OK
*   server certificate status verification SKIPPED
*   common name: dev.to (matched)
*   server certificate expiration date OK
*   server certificate activation date OK
*   certificate public key: RSA
*   certificate version: #3
*   subject: CN=dev.to
*   start date: Tue, 07 Jan 2025 22:00:10 GMT
*   expire date: Sun, 08 Feb 2026 22:00:09 GMT
*   issuer: C=BE,O=GlobalSign nv-sa,CN=GlobalSign Atlas R3 DV TLS CA 2024 Q4
* ALPN: server accepted h2
* Connected to dev.to (151.101.66.217) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://dev.to/dev-charodeyka
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: dev.to]
* [HTTP/2] [1] [:path: /dev-charodeyka]
* [HTTP/2] [1] [user-agent: curl/8.12.1]
* [HTTP/2] [1] [accept: */*]
> GET /dev-charodeyka HTTP/2
> Host: dev.to
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 200
< server: Cowboy
....
< strict-transport-security: max-age=31557600
< content-length: 145678
<
<!DOCTYPE html>
<html lang="en">
  <head>
  ....
</html>

Again, same logic. Now, I hope you can read the output.
First, the dev.to address was resolved into an IP address:

Host dev.to:443 was resolved
* IPv4: 151.101.66.217, 151.101.2.217, 151.101.194.217, 151.101.130.217

However, not one, but many. Why?

4.1 Little extra info: multiple IP addresses horizontal scaling of web apps

Well, I told you networking stuff is cool, and now, dear reader, if you've read this far, you'll also learn about load balancing and horizontal/vertical scaling.

Small web applications that don’t have many visitors can run even on a Raspberry Pi (a tiny PC acting as a server). Indeed, they can even run on something like a phone or any device with limited computational power. However, when a website is pretty well-known - and it's not just a basic blog with zero interactivity, but more like an online shop or DEV.TO - one single server may not be enough to ensure that each user has nice smooth experience browsing it. And it's not only about server hardware specs like super-mega RAM or many many CPU cores; it's also about the network, haha. Network transmission speed does not multiply with number of cpu/ram.

There are two ways of dealing with the hardware resources deficit of a server where web app is running: horizontal and vertical scaling. Let’s say you created a web app and hosted it on a Raspberry Pi. Then you added some cool backend algorithms that do something for your users, so even though you only have a few users, the algorithms demand computational power. You upgrade your Raspberry Pi to something more powerful with more RAM and a better CPU. One important detail is that your website was coolest.site.eu, mapped to the IP 123.124.6.8 - the IP address of that Raspberry Pi. You replace the Raspberry Pi, move your app to the new device, and also bind the SAME IP to the new device. This is vertical scaling.

But what if your web app doesn’t do anything too computationally heavy, yet you have thousands of users accessing it simultaneously? Sure, you could replace your Raspberry Pi with a super-mega server, but that might not be the best use of resources. Instead, you could buy four more Raspberry Pi, duplicate your web app on 3 of them, and thus end up with four different IP addresses—because they can’t all share one IP. Then you’d take 4th Raspberry Pi, install any load balancing software on it (like Nginx), and use it as a "sorter" of requests sent by browsers of your website users when they try to access it. For example, if a thousand users try to reach your website, they won’t all slam into one single Raspberry Pi. Instead, their browsers’ requests land on Load balancer's Raspberry Pi first. It sees how busy each Raspberry Pi is and directs traffic to whichever Pi is least busy at that moment. That’s horizontal scaling, and what load balancer does is balance the load among all available servers.

Okay, next. As I mentioned before, HTTPS is the secure version of the HTTP protocol. If you look at the end of the curl output I shared above, once again we see HTML data in plain text—but only after the browser successfully establishes communication with one of dev.to’s servers that hosts the frontend code. That’s why in the Wireshark screenshot, when I tried to put my nose in a HTTPS network packet, I saw weird symbols instead of plain HTML. It’s because the data was encrypted.

4.2 About encryption

If I send you the message 12334 145 672 849, like this, you won’t understand it—unless you know we have a decryption map such as 1=h, 2=e, 3=l, 4=o, 5=w, 6=a, 7=r, 8=y, 9=u, which transforms the message into "hello how are you". You can then respond using the same "encryption key". Of course, this is a very simplified example. In real encryption scenarios, there are usually two keys: public and private.

In my simple example, public key will be containing this info: 1 -> ?, 2 -> ?, 3 -> ?, etc. From public key you only get partial information about encryption—you know how to encrypt the message - turn letters into numbers.
Private key is the secret part that completes the map—only the holder of the private key can reliably invert the numbers into letters.
The public key is indeed public, and it helps a client figure out how data will be encrypted by server. And where is the public key stored when we talk about servers that run websites and exposes them via https protocol? In a small document called a certificate.

Returning to the curl output:

0*   Trying 151.101.66.217:443...
* GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
* ALPN: curl offers h2,http/1.1
* found 152 certificates in /etc/ssl/certs/ca-certificates.crt
* found 456 certificates in /etc/ssl/certs
* SSL connection using TLS1.2 / ECDHE_RSA_CHACHA20_POLY1305
*   server certificate verification OK
*   server certificate status verification SKIPPED
*   common name: dev.to (matched)
*   server certificate expiration date OK
*   server certificate activation date OK
*   certificate public key: RSA
*   certificate version: #3
*   subject: CN=dev.to
*   start date: Tue, 07 Jan 2025 22:00:10 GMT
*   expire date: Sun, 08 Feb 2026 22:00:09 GMT
*   issuer: C=BE,O=GlobalSign nv-sa,CN=GlobalSign Atlas R3 DV TLS CA 2024 Q4
* ALPN: server accepted h2
* Connected to dev.to (151.101.66.217) port 443

Here, you see a certificate verification step because client (curl, in this case, but the same is for browser) found certificates. Where do they come from, and how does the browser (or curl) verify them?

4.3 TLS/SSL certificates

Well, these certificates were created by dev.to’s server admins. First, two keys were generated on the server: a public and a private key. The certificate includes the server’s public key and some extra data (domain name, organization info, etc.). The dev.to admins sent this certificate to a Certificate Authority (CA) to have it signed. In dev.to’s case, I can see the certificate was signed by CA called GlobalSign:

*   issuer: C=BE,O=GlobalSign nv-sa,CN=GlobalSign Atlas R3 DV TLS CA

That CA verified that dev.to actually owns the domain and then issued a signed certificate if everything was legitimate about this server and domain. The signed certificate is sent back to the dev.to server. After this, dev.to's server is equipped with its private key (secret) and its public key that got embedded in the signed certificate (this is not secret). This signed certificate is TLS/SSL certificate

When I try to access https://dev.to/dev-charodeyka via a browser:

I. My browser starts a connection via the Secure Socket Layer (SSL) protocol to the dev.to server:

* SSL connection using TLS1.2 / ECDHE_RSA_CHACHA20_POLY1305

II. The dev.to server sends its signed certificate (which contains the public key) to my browser.
III. My browser verifies the certificate (checks expiration, domain match, CA trust, etc.). You can see that checking process in the output:

*   server certificate verification OK
*   server certificate status verification SKIPPED
*   common name: dev.to (matched)
*   server certificate expiration date OK
*   server certificate activation date OK
*   certificate public key: RSA
*   certificate version: #3
*   subject: CN=dev.to
*   start date: Tue, 07 Jan 2025 22:00:10 GMT
*   expire date: Sun, 08 Feb 2026 22:00:09 GMT
*   issuer: C=BE,O=GlobalSign nv-sa,CN=GlobalSign Atlas R3 DV TLS CA 2024 Q4
* ALPN: server accepted h2

IV. After the certificate is verified and approved by my browser, the dev.to server and my browser establish a secure channel. Think of it like going into a private room so nobody else can hear what you're discussing with another person. In digital communication, that means all messages are encrypted in such a way that only the sender and recipient can understand them.

4.4 Secure communication channel

To create this secure channel, both my browser and dev.to server need to agree on encryption and decryption keys:

1) They agree on the TLS (Transport Layer Security) version and cipher format:

* SSL connection using TLS1.2 / ECDHE_RSA_CHACHA20_POLY1305

2) The dev.to server and my browser each create "ephemeral" key pairs for this specific session that my browser initialized.
3) They exchange the public parts of these ephemeral keys (encrypted with or signed by the dev.to server’s private key to ensure authenticity).
4) A shared secret (the session key) is computed on both ends - my browser and dev.to server.

Now, my browser and the dev.to server each have the same session key. All the HTML, images, and everything else is encrypted with this session key—and it’s unique to this session.

Finally, once this secure channel is established, my browser sends encrypted HTTP requests and receives encrypted responses (like the HTML code for rendering my dev.to profile).

You can compare all these steps to the earlier HTTP Wireshark table—there, everything was visible in plain text. Under HTTPS, it’s all far not that clear. No one intercepting the packets from "outside" of the secured channel can read the data unless they managed to "steal" a secret key.

Well... I guess that’s all for networking fundamentals in the context of web development. This article got quite long.

The next (and concluding) part of this series will be mostly centered around the backend side of web development and JavaScript, but from a particular perspective - here is a teaser: can you use JavaScript the same you use Python?

Summarizing:

Don’t ignore the networking and servers. Even if you’re aiming to become a CSS/HTML/JS guru who can create amazing UIs, remember that understanding how servers and networking work is crucial. Otherwise, your frontend code could unintentionally breach security and expose sensitive data. Web dev isn’t just about pretty visuals; it’s also about safe and efficient communication between clients and servers.
HTTPS is more complex than HTTP; it’s not simply a "version 2" of HTTP. Developing on HTTP and localhost won’t behave exactly the same as when you switch to HTTPS in production. Secure cookies, CORS, and encrypted data transfers all tax your code once communication passes from HTTP to HTTPS.
Get familiar with how ports work and how to monitor them. You don’t want to open a bazillion ports in your web app by repeatedly opening up database clients or other services each on a new port.
Understanding URLs is vital for setting up routing in your web apps, especially when you deal with protected endpoints that require authorization.
Understanding IP addresses is just basic for any IT field. It will prevent you from sending your friend a URL to evaluate your cool web app that has as address your home network’s 192.168.x.x address.

A privacy-aware bonus that may encourage you to explore in-depth networking and DNS:

If you’re a privacy-obsessed and always use a VPN to surf the web like an untraceable ninja, ensure that DNS queries are never forwarded to your ISP’s DNS server. If they are, you are a traceable ninja.

Where to Start in Web Development: Your Browser as Your First IDE

aL — Sun, 09 Mar 2025 22:50:15 +0000

The reality of starting web development may be very confusing in the beginning. There are so many resources, courses, tutorials, and so on—but how do you choose the right one? Moreover, chances are that right from the start you’ll bump into React/Angular/Vue, because they are very popular frameworks, and it might seem like all web development can be done only with one of these frameworks and it begins with picking a "right" framework.

Plus, a lot of tutorials begin by setting up VS Code as the IDE (Integrated Development Environment). You start using VS Code, learn how to write .html and .css files, do some basic JavaScript scripting, and then—for simplicity—you install the VS Code Live Server. You click here, click there, maybe even run npm run... and—boom—your first web app appears in the browser. Enjoy!

But wait—what’s actually going on? localhost? Some port (:3000)? The browser complaining about an unsecured HTTP connection? JavaScript seems weird, and it’s not clear how or where to use it, or what the use cases are. How is the browser displaying your scripts so nicely? What is Node.js, and how did installing it on your PC allow the browser to execute JS scripts? So many questions might come up...

The worst thing you can do is leave these questions unanswered. As soon as you continue learning without truly understanding, these blind spots keep piling up. Eventually, you might realize you can’t develop anything based on your own ideas—at least not without following a step-by-step tutorial—because you don’t really know where to start.

In general, if you’re just discovering web development field and want to begin somewhere, starting with any of frameworks (React, Svelte, Vue and Angular are frameworks)—will only confuse you, because they’re definitely not the tools to start with web development.

Even though, of course, HTML, CSS, and JavaScript (further - JS) are the fundamentals of web development, but don't worry—this article isn't about that you just need to first master them and you will become web dev.

I am assuming that if you want to do web development, your final aim is to learn how to create web applications or websites—basically something that will be running in a browser.

And here is the first question:

How browsers work? What happens "behind the hood" when you open your browser and homepage shows on your screen? How does your browser manage to display all the web sites you visit?

You may be aware of the fact that most of the web applications have a "backend" that is residing on some mysterious "servers".

And here is the second question:

What exactly are the "backend" and "server," and how does a browser communicate with a "server"? Which code is considered "frontend," and which is "backend"? What determines whether some code belongs to one or the other?

If you cannot answer these question, that's "where" you must start in web development—by finding the answer to them.

In this series of articles I will provide the answers to these questions illustrating them with hands on code examples. I will be writing code in a very direct way—no IDEs, no frameworks, no extra stuff. Just a browser, my PC's Linux OS, and basic JS and HTML. Because I also want to show you that you can do many things with just basic tools and that only your imagination is the limit. You don't need React, Nginx, Express, Angular, VSCode Live Server or something else to start trying some web development.

So, let's start!

I’ve decided to write a set of articles on web development, rather than pack everything I want to share into one very long piece. This first article in the series—which you’re currently reading—will focus on using the browser as your powerful tool for web development. Here’s a roadmap:

Building confidence with a browser
1. Open random files in your browser to see what happens
2. Browser's Developer Tools as an IDE (Integrated Development Environment)
How does a browser work?
1. What is the document?
2. Browser's rendering engine
3. Document Object Model - DOM
4. Browser's JavaScript Interpreter

The second part of this web development series focuses on the browser's networking layer, specifically on URLs, the HTTP protocol, and a few must-know networking concepts in general. Although the networking field in IT isn’t simple, it’s a tough pill you have to swallow - if your goal is to get your web applications to a production-ready stage—rather than leaving them on your PC in some project folder, you must understand networks.

You might question this statement, especially if you’ve already explored the two well-known branches of web development—backend and frontend—and decided that frontend is what you want to do. However, even if you’ve chosen to focus on one, that doesn’t mean you can completely ignore the other. You still need at least the basic concepts and an understanding of how both "branches" work—frontend and backend. The third part of this set of articles will be dedicated to "backend" with a focus on what makes a code "frontend" or "backend".

NB! I use Linux, more precisely Debian, and I have an allergy to any other OS. So, if you use Windows or macOS, you might need to google how to do the same things on your system. Anyway, whatever I do in this article is not related in any way to the type of Operational System.

1. Building confidence with a browser

If before web development you were just a user of your preferred browser, that golden time is over—now it's your working horse if you're aiming to be a front-end developer. As a user, you might be very picky about browsers, choosing one that suits you. But the moment you decide to do front-end, hehe, soon you will install all the most common browsers for testing purposes—at least one per engine group they use (yes, even Microsoft Edge). I'll explain why later.

So, the browser... Now, I am writing this article in the browser. In a tab I am working I see in the address bar something like this:

https://dev.to/dev-charodeyka/where-to-start-in-web-development-bla-bla/edit

And if I go to any other webpage, I'll see something like:

https://some-site/home

You may have noticed that you can use your browser not only just to view web sites, but also to open images, PDF files, and other types of files. For example, I don't have any PDF reader on my system, so I use the browser to view PDF files if needed.

1.1 Open random files in your browser to see what happens

Okay, so I open LibreOffice, drop some random text, and save it as a PDF on my PC and... I open it in the browser by typing in the address bar: file:///home/lalala/Projects/DEVTO/webdev/randomPDF.pdf.

Little remark: pay attention to how a local file stored on my PC is opened in the browser vs how websites are opened— "file:///home/lalala/..." vs "https://some-site/home..". Do you notice the same syntax? The key part to notice is: https:// and file:// (third / in file:///home/lalala/... belongs to the absolute path of the file). It is important, I will return to this later in the article.

And here is what I see when I open a randomPDF.pdf file in my Browser:

What if I want to view a text file with the same content instead of a PDF?

# first, I create it 
$ vim randomTXT.txt
Hellow!
I am a TXT file!
I am visualized in a browser!

Then I paste this into browser's address bar to open text file: file:///home/lalala/Projects/DEVTO/webdev/randomTXT.txt

As you can see, the text is just text—there’s no bigger font for a title line, because the TXT format does not provide any way to format/style the text... but a Hyper*Text **Markup **L*anguage does—let’s create one!

# first, I create it 
$ vim randomHTML.html
<h1>Hellow!</h1>
<h3>I am a TXT file!</h3>
<p>I am visualized in a browser!</p>

I paste this into browser's address bar: file:///home/lalala/Projects/DEVTO/webdev/randomHTML.html
Here is the result:

Let's add some spice - styling of one word with Cascading Style Sheets - a style sheet language used for specifying the presentation and styling of a document written in a markup language:

$ vim randomHTML.html
<h1>Hellow!</h1>
<h3>I am a random <span style="color: red;">HTML</span> file!</h3>
<p>I am visualized in a browser!</p>

Result:

I demonstrated HTML and CSS in action. If I want to display more text or change the color of some words, is modifying randomHTML.html file and then refresh the browser's page to see the changes is the only way to do it? Heh, of course not.

1.2 Browser's Developer Tools as an IDE (Integrated Development Environment)

First, I have to open the developer tools (hereafter, "dev tools") in my browser. If you're not sure how to open dev tools, you can easily find instructions online. A common method is to right-click anywhere on the page and select "Inspect" from the drop-down menu; however, this option may not always be available, as some websites block it. In that case, you can launch the dev tools from your browser's control panel, where you also can check a specific keyboard shortcut they are usually tied to.

This is how my chromium based browser Brave dev tools look like (the quality of screenshot is not the best due to the automatic compression of DEVTO attachments):

Development tools of my Brave browsers are grouped into Elements, Console, Sources, Network, Performance, Memory, Application, Security. I add/delete/modify HTML elements from Elements Tab.

Using dev tools I can add/delete/modify HTML elements and CSS styles for them "on the fly". Of course dev tools are a pretty powerful tool and are not meant only for these silly modifications, but I just wanted to demonstrate how you can easily experiment with HTML and CSS directly from a browser.

However, keep in mind that whatever I do with the browser’s dev tools doesn’t affect the original .html file that I opened in the browser—all changes will be lost if I don’t save them into a separate file. The same is true for any web page you inspect with dev tools and eventually modify something - of course it does not affect permanently the original page in any way.

Okay, I played a bit with HTML and CSS from Elements tab of dev tools. There’s another interesting tab in these tools called Console, which is an interactive shell where I can write some JS code and execute it!

Some silly "print" of the sum of two numbers and a couple of evaluations of expressions:

//JS code I ran in the Browser's console:
const a = 2
const b = 3
a>b
a===b
a<b
console.log(a+b)

And you know what? Why not add a new HTML element to the displayed .html file's content opened in a browser with JS? Because JS is definitely capable of it:

//JS code I used to add a new text to my HTML document:

//first, I add <div>
const newRandomDiv = document.createElement('div');
//then, I add child of <div>, <p> with some text
newRandomDiv.innerHTML = '<p>Hellow, I was added by JavaScript!!!</p>';
//my HTML document has the <body>, so I append new element as a child of it
document.body.appendChild(newRandomDiv);

However, you might ask: what is the document? I opened the Console of dev tools and haven’t declared any document variable or anything like that—where does it come from? I guess it’s obvious that the document in question is related to the HTML file that’s open in the tab:

2. How does a browser work?

On the screenshot above, you can see that I used the browser’s JavaScript interactive shell to "print" the document. From the output it is clear that it contains HTML elements from the original .html file I opened in the browser, plus some other elements that I added manually by directly editing the HTML structure in the dev tools and also using JavaScript from the browser. However, what was not originally in the randomHTML.html file that I opened are the tags like <html>,<head> and <body>.

The <html> tag represents the root of an HTML document. The tag defines the document's body.
The <body> element contains all the contents of an HTML document, such as headings, paragraphs, images, hyperlinks, tables, lists, etc.

2.1 What is the `document`?

Everything, that is enclosed between <html></html> tags is the document. And, roughly speaking, that is what web development (front-end part) is about: working on this document - bending it, mangling it, shaping it to make it look how you want. When I opened randomHTML.html file with the browser I loaded this file into the browser, and its content became a part of document object.

When an HTML document is loaded into a web browser, it becomes a document object.
The document object is the root node of the HTML document.
The document object is a property of the window object.
The document object is accessed with: window.document or just document (W3Schools: HTML DOM Documents)

What about the TXT and PDF files that I opened before? Well, their content also become a part of document objects, when I open them in the browser.

This is the .txt file opened in my browser when I inspect the tab's content with dev tools:

<html>
  <head>
    <meta name="color-scheme" content="light dark">
  </head>
  <body>
    <pre style="word-wrap: break-word; white-space: pre-wrap;">Hellow!
     I am a random TXT file!
     I am visualized in a browser!
    </pre>
  </body>
</html>

You may notice how interestingly the raw text file content was "wrapped" into an HTML document object by my browser. It is not uncommon for modern browsers to create a minimal HTML "wrapper" for a content that a browser was requested to display and that it managed to recognize.

In the plain text file, there was no any styling, like the first line in bold and enlarged font. But content of the .txt file has the line breaks. They were preserved by the browser by attaching CSS rules for word-breaking, white space, and word wrapping!

Let's have a look on the document object structure of PDF file opened in the browser:

<html>
  <head>
  </head>
  <body style="height: 100%; width: 100%; overflow: hidden; margin:0px; background-color: rgb(82, 86, 89);">
    <embed name="DDDBE1725B1DA9C2C0B9CFA699CCB3B9" style="position:absolute; left: 0; top: 0;" width="100%" height="100%" src="about:blank" type="application/pdf" internalid="DDDBE1725B1DA9C2C0B9CFA699CCB3B9">
  </body>
</html>

What is similar to a .txt file is that the browser’s PDF viewer is embedded in a minimal HTML document. While with a text file I was able to see the actual file's content directly and even modify it right from the browser, with a PDF file it's not the same. This kind of embedding is actually a byproduct of how my browser handles and renders PDF files.

Can I mess it up with how PDF file is displayed using dev tools even if it is originally PDF file? Sure:

Here is JS code I used:

const redThingy = document.createElement('div');
redThingy.style.backgroundColor = 'red';

redThingy.style.width = '400px';
redThingy.style.height = '400px';

redThingy.style.position = 'absolute';
redThingy.style.top = '50%';
redThingy.style.left = '50%';
redThingy.style.transform = 'translate(-50%, -50%)';

redThingy.innerHTML = '<p>Hello, I was added by JavaScript to <span style="color: yellow;">mess up</span> PDF!!!</p>';

document.body.appendChild(redThingy);

However, obviously, this red box with text didn’t affect the PDF file itself in any way. What my modifications actually affected was just how my browser rendered the opened PDF file.

I guess it’s time to summarize the point of all of these experiments.

As you can see, a browser is a powerful tool. It's not just an "app" to open websites with added features like a photo viewer or PDF viewer.

2.2 Browser's rendering engine

Any browser has its own engine that renders what you see on its User Interface (UI). Roughly speaking, to render anything a browser uses instructions in a markup language—HTML.

Different browsers work differently. However, let me explain the process slightly generalizing:

When you enter a query in the browser's search bar (a URL), networking layer of the browser delivers your "request" to a destination point that is retrieved from URL and bring back to browser a response which could be any type of file or data. Some file types can’t be displayed directly (for example, if the file is corrupted or has an unrecognized format), in which case the browser may display an error or prompt you to download it instead.
If the received data is recognized as HTML, the browser parses it to build a Document Object Model (DOM) tree. This process involves reading the HTML and turning it into a structured hierarchy of nodes that represent the page’s elements. If the received data isn’t HTML but the browser can still display it (like plain text or PDF), the browser will process it in a specialized way. For plain text files, most browsers apply a minimal HTML “wrapper”; for PDFs, the browser’s PDF viewer is embedded in within an HTML context, so browser can position it, handle scrolling, zoom, and so on.
The browser then creates or updates a render tree, which is the combination of the DOM and the CSSOM (the CSS Object Model). The layout step figures out the exact positions and sizes of all elements on the page.
Finally, the browser paints (or “rasterizes”) the render tree onto your screen. This is what you actually see in the browser’s viewport.

There are many variables in the rendering process. Every element in the DOM tree is an object that the browser needs to render by calculating its position (this is where responsive design comes in, since an element’s positioning depends heavily on the available space on the user’s device), appearance, and any dynamic changes. The DOM tree isn’t static; the browser continually re-renders it as elements move or change appearance—like those animations you see on some websites.

2.3 Document Object Model - DOM

I want to elaborate more on the DOM tree.

The backbone of any HTML document is its tags. In the Document Object Model (DOM), every HTML tag is an object. Nested tags are considered “children” of the enclosing tag, and even the text inside a tag is treated as an object. The DOM represents HTML as a tree structure of tags. (Source)

<html>
  <head>
  </head>
  <body>
    <h1>...</h1>
    <div>...</div>
    <...>...</...>
  </body>
</html>

You can notice the nested structure of HTML document: each tag is an object, and the nesting forms a tree-like hierarchy.

I'm repeating this: if you're aiming to be a front-end developer, the DOM is everything. In front-end development, almost everything ultimately revolves around DOM manipulation. I've shown how to manipulate the DOM using browser's dev tools—adding HTML elements, applying CSS, and most importantly, doing it through JS. Because in front-end development, JS is primarily about manipulating the objects in the DOM tree, which are (at their core) HTML elements.

All these DOM objects are accessible via JavaScript. I’ve only shown a small part, and it might have seemed very easy. Well, it was easy because I was working directly with those DOM objects—there were only a few, and everything was clear.

But remember this: the JS libraries you use to "simplify" certain features—and especially any framework (React, Angular, Vue, etc., though each to a different extent)—actually take you one step further away from direct manipulation of the DOM objects.

Frameworks abstract direct DOM manipulation, so you write your code in a more declarative way. Behind the scene, any framework still manipulates the DOM — but you interact with a framework’s abstractions instead of directly selecting or updating DOM elements.

The key point is that these abstractions are not "bad" - they make development more efficient and your code more maintainable, as long as you have a basic understanding of how the DOM works. If you rely on abstractions without knowing what’s happening underneath, you are cooked. No fancy framework will make you a good developer if you don’t at least keep the DOM tree in mind whenever you manipulate it with JS.

I’ve shown how to do manipulate DOM directly in the browser—not to promote this style of coding (obviously, no one codes like this for a full project). I just wanted to show you what your browser is truly capable of. Everything I did was handled entirely by the browser—there was no server behind it, no external tools, just the browser.

2.4 Browser's JavaScript Interpreter

And this leads to a very important point: I was able to execute JavaScript in the browser because browsers have a built-in JavaScript interpreter. Think about it—if you’re a Python developer, before you could run Python code, you had to install Python on your PC (unless you're on Linux, where it's usually pre-installed). That’s because Python isn't machine code, so your PC can’t understand it without an interpreter. The same goes for JavaScript. The key point is that modern browsers come with a JavaScript interpreter embedded in their engine.

Sounds great, right? But here’s the cornerstone: different browsers have slightly different JavaScript interpreters inside their engines. For basic, standard JavaScript usage, this isn’t a big deal. But when you get into non-standard usage, things get trickier. And every external library you add to your code potentially brings you slightly closer to using a JS in "non-standard" way that may be not supported by some browsers. And these browsers may be the favorite browser of potential users of your web applications :).

To conclude, here is a very generalized scheme of how browsers work:

In the next article of this series on Web Development, I’ll elaborate on the format of the "query" you see in the browser’s search bar, as well as the role of "servers".

This query format is very important—I’d even call it crucial— because the routing in your future web apps result in these "queries".

Jumping ahead, I should mention that "query" is actually a bit of an oversimplification of what appears in the address bar, because the correct technical term is URI (Uniform Resource Identifier). The true query is just one part of a URI, and URIs are closely tied to the HTTP protocol in web development, which in turn is tied to networking.

In the next article, I’ll do my best to simplify and clarify all these concepts!

Summarizing the main points:

Browsers have a built-in JS interpreter and they do run JS code.
The browser’s JS interpreter is not the same as your PC (or server)’s JS interpreter—they’re different. Keep this in mind.
The internal components of browsers are complex, and each browser implements them differently. In my humble opinion, that’s what makes the frontend part harder than the backend in modern architectures.
You need to understand both backend and frontend to be a good web developer—you can’t just master one and completely ignore the other.
In front-end development, almost everything ultimately revolves around DOM manipulation (= you have to understand the concept of DOM as clear as possible)
If "network" for you only means "the Wi-Fi at home", you must invest your time in studying networking.

Virtualization on Debian with libvirt&QEMU&KVM — Networking beyond "default": Forwarding Incoming Connections to NAT'ed network

aL — Mon, 27 Jan 2025 23:30:02 +0000

This is the second part of "Networking Beyond "Default". All must-have theory was explained in detail in the previous part, this article will be very practical.

If your understanding of these concepts is very wobbly, I strongly recommend reading the previous article:

nftables rules that perform network address translation
The structure of IPv4 addresses and CIDR
Physical vs Virtual Network Interfaces
Virtual network switches a.k.a bridges

Terminology I will use in this article:

Host – This refers to your PC, on which you set up virtualization and create virtual machines.
Guest – This is any virtual machine you create. VM/VMs – A virtual machine/Virtual Machines.
LAN – Local Area Network managed by my WiFi Router provided by ISP(Internet service Provider)
NAT – Network Address Translation.
DEFAULT network – the Libvirt's virtual network that virtual machines are connected to by default (gets started with sudo virsh net-start default)
Packet - a network packet is a formatted unit of data carried by a network.

As I have spitted the content on virtualization into 3+ articles, I’ll start with a quick overview of my current setup and the goals I want to achieve with different network configurations.

My virtual machines are created under qemu:///system, which means I run all virsh commands with sudo. Using sudo privileges allows me to configure the network as I need, whereas qemu:///session has very limited permissions in hardware virtualization (for more details, check this article).
My host machine runs Debian, with nftables managing network traffic and firewalld serving as the firewall management tool.
I have a virtual machine running MongoDB (VM name: deb-mongo). This VM was created in the most basic way and is attached to the DEFAULT libvirt network. Here’s what that entails:

The deb-mongo VM can communicate with other VMs connected to the same DEFAULT network, which operates in the NAT mode.
The VM can communicate with the host in both directions—whether the host initiates the connection (e.g., via SSH) or the VM initiates it.
The VM has access to the internet, allowing me to install MongoDB, update system packages, use ping, curl, wget, and so on.
No device on my local home network (the same network the host is on) can access this VM directly, and of course, nothing from the outside my home LAN can reach it either.

What I want to achieve, for demonstration purposes, is to make the deb-mongo VM reachable from my laptop, which is on the same local home network as the host (My Desktop PC). I want to be able to connect to MongoDB running on the VM using the MongoDB Compass GUI client on my laptop.

In the previous article, I analyzed libvirt's DEFAULT network in detail and broke its configuration down into small pieces. If you were paying close attention, you would have already understood which nftables rules block connections from anything other than the host machine to the VMs connected to DEFAULT network.

In the scope of this article I plan to enable access to the VM from devices connected to my LAN by modifying nftables rules of DEFAULT network, plus configure port forwarding on the host.

This option is viable, however, it is about turning a well-defined libvirt’s DEFAULT network into something different, which it was not meant to be.

I wrote this tutorial for educational purposes as I noticed that the questions about how to do it can be found on all possible forums for different distros. Personally, I do not use this network configuration in my home lab, and later in this article it will become clear why.

At some point, it’s better to define a new virtual network from scratch and define rules and NAT for it, rather than modify libvirt’s DEFAULT one, if you are very “NATophile”.

However, I can assume, that you are not, just maybe you think that is the only option to make VMs reachable for other devices connected to LAN. But it is not true. In the next article I will cover more suitable network configuration for the use case when VMs should be accessible members of LAN.

Now, let's begin with DEFAULT network tweaking!

Here is the roadmap for this article:

➀ DEFAULT libvirt network

➀.➀ virbrN and vnetN - what do they do?
➀.➁ About DHCP

➁ Configuring static IPv4 address on VM

➁.➀ Shrinking DHCP range
➁.➁ Modifying /etc/network/interfaces

➂ Connecting to a VM from Another Device on the LAN using the Port Forwarding Method:

➂.➀ What is the Port Forwarding?
➂.➁ Firewalld and open ports
➂.➂ Forwarding ports on the host with firewalld
➂.➃ Adding a rule to nftables ruleset to accept inbound network traffic to the VM
➂.➄ Considerable drawbacks of this method

➀ DEFAULT libvirt network

First, I start the DEFAULT network, then I start the VM deb-mongo and enter its console.

# ip a serves to show when virtual network interfaces appear
$ ip a
1: lo
 ...
2: eno1:
    inet 192.168.1.X/24 brd 
3: wlx123456789kl:
    inet 192.168.1.Y/24

$ sudo virsh net-start default

$ ip a
1: lo
 ...
2: eno1:
    inet 192.168.1.X/24 brd 
3: wlx123456789kl:
    inet 192.168.1.Y/24
4: virbr0:
    inet 192.168.122.1/24

$ sudo virsh start deb-mongo

$ ip a
1: lo
 ...
2: eno1:
    inet 192.168.1.X/24 brd 
3: wlx123456789kl:
    inet 192.168.1.Y/24
4: virbr0:
    inet 192.168.122.1/24
5: vnet0: 
    inet ???

$ sudo virsh console deb-mongo

➀.➀ `virbrN` and `vnetN` - what do they do?

First, I want to schematize what these virbr0 and vnet0 network interfaces. They weren’t there initially (ip link/ip a before sudo virsh net-start default did not contain them in outputs), but virbr0 showed up after I started the DEFAULT network, and vnet0 appeared when I started the deb-mongo VM.

virbr0 is the virtual network switch, and while its name suggests it is a bridge (and bridges are generally used to connect different networks), in the case of the DEFAULT libvirt network, virbr0 doesn't bridge anything - it does not bridge the DEFAULT network (192.168.122.0/24) to any of the networks the host is connected to. In a more physical sense, no physical network interface is plugged into this virbr0. All network traffic between VM and host, between VM and the outside world is governed by NAT (Network Address Translation) configuration.

This is partially why no VM connected to the DEFAULT network can be reached from other devices on your local home network, which the host is connected to. The other reason lies in the rules that define NAT, which essentially translate and isolate the internal network traffic.

vnet0 is a network TUN device. TUN/TAP devices are kernel virtual network devices. Being network devices supported entirely in software, they differ from ordinary network devices which are backed by physical network adapters.

The guest VM will have an associated tun device created with a name of vnetN, which can also be overridden with the element. The tun device will be attached to the bridge.This provides the guest VM full incoming & outgoing net access just like a physical machine. (Libvirt:Network Interfaces)

Let's move on.

If you check above the latest ip a output from my host PC, you'll notice there is no IPv4 address associated with the vnet0 interface, which is the virtual network interface of my VM deb-mongo. So, to proceed, I need to check the IP address of the VM directly from the VM itself.

I want to connect to the MongoDB instance running on this VM using the MongoDB Compass GUI client installed on my host machine. To do this, the first step is finding the IP address of the VM.

user-mongo@deb-mongo:~$ ip a
1: lo: 
...
2: enp1s0: 
    inet 192.168.122.196/24 brd 192.168.122.255

That's quite a strange IP address, especially considering this is the second VM created in this network. 192.168.122.1 is the address used by virbr0, which acts as the router/gateway for this DEFAULT network (I'll elaborate more on it later). So why is my VM's IP .196 instead of something like .2 or .3? Where did it get this address? The answer is that it got it from DHCP - the Dynamic Host Configuration Protocol.

➀.➁ About DHCP

When you set up any network, any device connecting to this network needs to have certain information, such as the IP-address of its interface, the IP-address of at least one domain name server, and the IP-address of a server in the LAN that serves as a router to the internet. In the manual setup you have to type in this information for each client anew. With the Dynamic Host Configuration Protocol (DHCP) the computers can do that automatically for you. (Source)

Each virtual network switch can be given a range of IP addresses, to be provided to guests through DHCP.
Libvirt uses a program, dnsmasq, for this. An instance of dnsmasq is automatically configured and started by libvirt for each virtual network switch needing it. (Libvirt: Network Address Translation-NAT)

As stated in the libvirt documentation quoted above, I expect to find in the network configuration the range of IPs that the DHCP server is configured to assign. Indeed:

$ sudo virsh net-dumpxml default

<network>
  <name>default</name>
  <uuid>2becd6d0-5a0f-4b45-afff-5a518370fc8c</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='MA:C:AD:DD:RE:SS'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

DHCP automatically assigns IPs to the connected to DEFAULT network virtual machines from the range 192.168.122.2 - 192.168.122.254, based on availability rather than strictly sequential allocation. That’s why my VM ended up with .196.

What DHCP does respect when assigning IPs is that it keeps track of what’s happening in the network it manages. It won’t assign an IP that’s already currently occupied to new VMs joining the network. However, unless configured otherwise, DHCP won’t intervene if two VMs somehow end up with the same IP, and that can create a mess.

Why would this happen, you might ask? Well, it’s not uncommon to change the DHCP mode from dynamic IP allocation to static IPs (manually assigned). With the default setup, DHCP assigns dynamic addresses, so when a device connects to the network, it gets an IP like X. But if it disconnects and reconnects later, it might be assigned a completely different IP like Y, which can be very inconvenient for certain services that need to be accessed remotely.

➁ Configuring static IPv4 address on a VM

NB! It’s not being said for sure that DHCP is some crazy guy randomly assigning IP addresses by just looking at new connections and completely ignoring whether a device (like a VM's network interface) was already connected before. In fact, it’s very common for the IP address assigned once to persist. This is because the VM’s network interface, even if virtual, has a consistent and unchanging MAC address - so, it can be identified.

Anytime the VM reconnects to the same network, it will 99.9% get the same IP address as it was assigned the first time. However, sometimes certain factors can cause DHCP to reassign a different address.

On top of that, you may want to bring some order to your VMs, especially if there’s a logical structure to them, and you’d like more control over their network configuration. Assigning static IP addresses can help with this. While static IPs introduce some network fragility, they also improve network security, as you can create firewall rules, nftables rules, etc., based on the fixed IPs.

Of course, you can still set up such rules with DHCP-assigned dynamic IPs. However, the problem arises if the VM’s IP address changes for any reason. In that case, all the carefully imposed network traffic rules would collapse, and the setup would need to be reconfigured.

Moreover, knowing how to configure VM's network interface in the way you want it to is very nice skill to have, IMHO.

To manually assign a static IP to a VM, there are two things to respect: the range of network - I cannot assign IP address out of range; unique IP address - no any other VMs should have the same IP.

➁.➀ Shrinking DHCP range

To prevent, from the start, the possibility that DHCP assigns to a new VM an IP address I manually glued to one of the VMs by reconfiguring its network interface, I have to modify the DEFAULT network configuration and shrink the DHCP range—the set of available addresses that DHCP can use to assign.

Currently, this range occupies all the addresses available in the 192.168.122.0/24 network—all 254 addresses, excluding those reserved for the gateway/router (virbr0) and the broadcast address. By shrinking this range, I ensure there are IPs left outside the DHCP range that I can assign manually to specific VMs without interference.

#to prevent problems with VM connectivity
$ sudo virsh destroy deb-mongo

$ sudo virsh net-edit default
#I replace this:
<network>
...
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
---> <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>
#with:
<network>
...
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
---> <range start='192.168.122.101' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

# restart DEFAULT network
$ sudo virsh net-destroy default
$ sudo virsh net-start default

# check that changes came in power:
$ sudo virsh net-dumpxml default

➁.➁ Modifying `/etc/network/interfaces`

As it was found out earlier, the current IP of deb-mongo VM is 192.168.122.196. To change this IP I will have to modify configurations of network interface stored in /etc/network/interfaces

user-mongo@deb-mongo:~$ sudo vim.tiny /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet dhcp <--here is what I need to change

# I comment out the line: #iface enp1s0 inet dhcp and replace it with:
iface enp1s0 inet static

With this line (iface enp1s0 inet static), I just switched the mode of interface configuration from dhcp to static, which means I now have to configure it manually. My goal is to assign an IP address of my choice, which can be set using the address field. However, if you were attentive to the previous section, you’d know that DHCP doesn’t just assign an IP address—it also provides the device (the network interface of the VM) with crucial information about the network it’s connecting to. More specifically, it provides details such as the size of the network (netmask) and the IP address of the gateway. Since I switched to static mode, I need to manually provide the following details in the configuration: address, gateway, and netmask.

address 192.168.122.10 is the IP address I want this VM to have persistently. You can choose any number outside the range .

Information about the gateway and netmask is taken from this part of the network configuration:

  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.101' end='192.168.122.254'/>
    </dhcp>
  </ip>

Gateway is ip address='192.168.122.1', netmask is netmask='255.255.255.0'. With the netmask, it’s pretty straightforward—it corresponds to the CIDR notation of the network. For example, /24 equals 255.255.255.0, with the last 0 indicating the part of the IP address range that is available for assignment. This defines the size of the network.

But what about the gateway? Remember the previous article's explanation about network switches? In the DEFAULT network, this job is handled by virbr0. All VMs connected to this virtual network switch become part of the same network, and they are allowed to communicate with each other (as per the nftables rules set by libvirt).

It’s not just that by connecting to the same virtual network switch, VMs can magically communicate directly with one another. No, there is a network switch in between EACH COMMUNICATION, acting like a post office. When you want to send a letter to someone, you write the letter, put the destination address on it, and bring it to the post office—you don’t usually travel to the recipient’s address and deliver it manually. The post office handles everything, ensuring the letter is delivered.

The same logic applies to the network switch, and in the case of the DEFAULT network, this role is performed by virbr0, which acts as the gateway. Gateways, as a technical term, are broader than just routers or switches because they can perform a variety of tasks. It is important for the VM to know where to find the gateway in order to communicate via it with other network devices and with the outside world (if allowed). Regardless, the gateway (virbr0) will decide how to handle any communication sent from the VMs connected to it. virbr0 IP address is 192.168.122.1 (can validate with ip a).

This information ends up in the configuration file /etc/network/interfaces:

....
....
#iface enp1s0 inet dhcp
iface enp1s0 inet static
  address 192.168.122.10
  netmask 255.255.255.0
  gateway 192.168.122.1

Then, I restart networking systemd service:

user-mongo@deb-mongo:~$ sudo systemctl restart networking
user-mongo@deb-momgo:~$ ip a
1: lo: 
....
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP ...
    link/ether ...
    inet 192.168.122.10/24 brd 192.168.122.255

# to check if nothing went messed up:
user-mongo@deb-momgo:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=17.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=17.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=16.5 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

#try to update system packages
user-mongo@deb-momgo:~$ sudo apt update && upgrade
...
Fetched 485 kB in 1s (901 kB/s)
...
All packages are up to date.

#try to ssh from HOST MACHINE
ssh user-mongo@192.168.122.10
...
Are you sure you want to continue connecting (yes/no/[fingerprint])?
#It is requesting you again to accept the fingerprint, because you change "address" of a VM
#Anyway ssh is successful

NB! If you experience any problems with VM's connectivity to the internet, try the following steps:

Destroy the network with sudo virsh net-destroy default;
stop the VM with sudo virsh destroy <vm-name>; restart the libvirtd service with sudo systemctl restart libvirtd; start the network with sudo virsh net-start default; start the VM again with sudo virsh start <vm-name>. Restarted VM should not have problems with connectivity. If connectivity still doesn’t work after these steps, then something got messed up wrong with the configuration.

So now, I should be able to connect to the MongoDB running on my VM deb-mongo from the host using the MongoDB Compass GUI client.

For demonstration purposes, I didn’t configure any sophisticated RBAC for the database, so all I need to connect is the IP address and the port through which the database is accessible. Here is the MongoDB configuration on the VM:

$ user-mongo@deb-mongo:~$ cat /etc/mongof.conf
...
# network interfaces
net:
  port: 27017
  bindIp: 192.168.122.10
...

Voila:

Now, the objective is to modify configurations of the DEFAULT network in such a way that I can connect to MongoDB on the VM from a laptop that is connected via Wi-Fi to the same local home network as my PC (host).

➂ Connecting to a VM from Another Device on the LAN using the Port Forwarding Method:

This is what Port Forwarding method is about:

As I’ve pointed out more than once, 192.168.122.10 belongs to a different network than 192.168.1.0/24 (my home's LAN). virbr0 does not bridge any physical interface of my host PC that is connected to the LAN with the DEFAULT network. As a result, the VM’s address is unreachable for any device connected to the LAN.

However, the devices connected to my home's LAN can communicate between themselves.

➂.➀ What is the Port Forwarding?

If you are a developer and work on remote servers using VSCode as IDE, most probably you’ve already used port forwarding indirectly. For example, when you’re developing something like a web app during its early stages, it’s common for the app’s components—backend or frontend—to run on the server’s localhost using specific development ports. However, when you connect to this server via VSCode and update the code, you can see in the browser the preliminary results on your development machine (let's call it laptop), not on the server’s browser.

Here’s the point: let’s say your frontend app is running on the server’s localhost at port 5173. If you try to access it directly from your laptop’s browser, you won’t see anything. That’s because the app is running on the server, not your laptop. Without port forwarding, the server’s localhost is inaccessible to your laptop.

What happens, often with just two clicks—and sometimes even automatically in VSCode—is port forwarding. This forwards the server’s port (e.g., 5173) to a port on your laptop. As a result, you can open the browser on your laptop and see your app at an address like http://localhost:5173. What you’re actually seeing is the server’s localhost:5173, forwarded to your laptop.

So, I’m about to do something similar, bu with port forwarding on the host to the VM deb-mongo. On my host machine, there’s no MongoDB installed, but it is running on the VM. I want to use the host machine as a kind of layover "airport" for the network packets traveling from my laptop to the VM to reach the database (the MongoDB Compass GUI client on my laptop exchanges packets with the MongoDB server and translates the packet payloads into the visualizations I see).

The layover airport analogy fits perfectly here. In real life, layovers are a common practice, and the most interesting parallel is with visas. For instance, let’s say you’re traveling to Brazil from your home country. Based on a bilateral agreement between your country and Brazil, you don’t need a visa to enter Brazil. However, your flight has a layover in the UK, and to enter the UK, you do need a visa. Here’s where it gets interesting: if you’re just transiting through the UK and stay within the airport's transit zone, you don’t need a true UK visa (let's leave aside transition visa). As long as you don’t exit the airport, everything works perfectly. But if you try to leave the transit zone, UK authorities will block you because you’re not permitted to enter UK without a true visa.

Similarly, in networking, my host machine acts as the "layover airport." Packets from my laptop need to travel through this transit point (the host) to reach the MongoDB instance running on the VM. As long as the host is correctly configured to forward packets (like a transit zone in an airport), everything flows smoothly. If, however, the laptop tries to directly access the VM (bypassing the host’s forwarding), the packets will fail because they are not permitted to "enter".

Anyway, why do I speak so much about permissions? Because if you use firewalld or any other firewall that’s up and running, they usually protect your device from unauthorized access. By default, all ports on your host are closed for NEW connections. However, ESTABLISHED and RELATED connections are often allowed, meaning that network packets can navigate through them. ESTABLISHED means the connection was initiated by the device itself (remember the distinction between inbound vs outbound traffic from the previous article?).

What I want to do is use a random port, 12345, on my host machine as a "dummy port" that my laptop can connect via LAN to using the TCP protocol. I want that all network packets sent by my laptop to my host's IP:12345 will be redirected to the VM deb-mongo, specifically to MongoDB’s default port, 27017, and the same for network packets with response from MongoDB.

➂.➁ Firewalld and closed ports

Now, for demonstration purposes, I’ll show you that a connection to this port (12345) on my host is not allowed by firewalld. I’m using the netcat-openbsd package to perform this simulation. It’s installed on both my laptop and my PC (the host).

On the host, I start listening on port 12345. This is just a random listener; there isn’t any service running on this port. It’s not like the case with MongoDB, where MongoDB listens on its default port and expects specific syntax that it can understand. With netcat, I can send any nonsense via TCP, and the listener will still accept it without validation—because it’s just a raw socket tool.

On my host I start a listener on port 12345

$ nc -lv 12345
Listening on 0.0.0.0 12345

From the laptop I try to send a message to the host private IP, port 12345:

$ echo "hellow from the laptop" | nc -v 192.168.1.106 12345
nc: connect to 192.168.1.106 1235 (tcp) failed: No route to host!

The connection fails. I start by investigating the firewalld rules because I’m sure it’s responsible for blocking the connection. And indeed:

$ sudo firewall-cmd --query-port=12345/tcp
no

This confirms that port 12345 is not open (read: no any device can connect to my host via this port). Next, I control which zones are being used for my network interfaces. firewalld applies rules based on zones. However, explaining zones in detail is outside the scope of this article (you can check the documentation here).

$ sudo firewall-cmd --get-active-zones
libvirt
  interfaces: virbr0
public (default)
  interfaces: wlx123456789kl

Not the best idea to modify firewall rules for the public zone, so I switch to the home zone, which is actually the technically correct one because my host is connected to my home's LAN.

$ sudo firewall-cmd --zone=home --change-interface=wlx123456789kl
success
$ sudo firewall-cmd --zone=home --query-port=12345/tcp
no

This port 12345 is also closed in the home zone, so I could just open it with sudo firewall-cmd --zone=home --add-port=12345/tcp. But I want to open it only to be accessible by the private IP address of my laptop. So I just add a rich rule instead.

Remember! Avoid, whenever you can, any wobbly rules for accepting something. Do not open ports to the whole world. Always try to minimize access and add precise, restrictive, and well-defined permissive rules.

$ sudo firewall-cmd --zone=home --add-rich-rule='rule family="ipv4" source address="192.168.1.105" port protocol="tcp" port="12345" accept'
success

And voilà: the message from my laptop successfully arrived at my host, port 12345:

$ sudo nc -lv 12345
Listening on 0.0.0.0 12345
Connection received on LAPTOP-1234567.station XXXXX
hellow from laptop!

NB! If you are unfamiliar with firewalld, you might not have noticed that I didn’t add these rules permanently. This means that when I reboot or reload the firewalld service, these rules will be lost—which is exactly what I wanted.

For port forwarding, the rule is different and doesn’t require keeping the port open on the host which will be forwarded. This is where my earlier example with visas is valid—packets that are simply transiting through my host don’t need permission from the firewall because they don’t actually "enter" my host at the end.

So, I’ve demonstrated and imposed these rules purely for educational purposes, and now I’ll flush them with sudo firewall-cmd --reload, as they’re no longer needed.

➂.➂ Forwarding ports on the host with `firewalld`

Now, I’ll forward the host’s port 12345 to the VM’s deb-mongo default MongoDB port 27017. I’ll do this by adding a rule with firewalld.

According to the firewalld documentation, this is how port forwarding should be done:

[--permanent] [--zone=zone] [--permanent] [--policy=policy] --add-forward-port=port=portid[-portid]:proto=protocol[:toport=portid[-portid]][:toaddr=address[/mask]] [--timeout=timeval]

As I flushed the rules from the example above, I first need to repeat the process of changing the zone for my WiFi interface from public to home. Once that’s done, I can apply the port forwarding rule. NB! I do not add --permanent option to the commands, but if you plan to keep these firewalld configurations, you will need to specify this option.

$ sudo firewall-cmd --zone=home --change-interface=wlx123456789kl
success
# THE RULE FOR PORT FORWARDING
$ sudo firewall-cmd --zone=home --add-forward-port=port=12345:proto=tcp:toport=27017:toaddr=192.168.122.10
success

So, can I connect now from my laptop to MongoDB running on the VM deb-mongo? No. However, half the job is done.

In the previous article, I described in very detailed way why any inbound traffic is blocked by rules specified in nftables that are placed there by libvirt. For the DEFAULT network, these NAT rules are configured to isolate VMs, allowing them to connect outbound but blocking any inbound traffic from external devices (except Host, of course). This is why the connection still fails.

➂.➃ Adding a rule to `nftables` ruleset to accept inbound network traffic to the VM

To fix this, I’ll need to adjust these nftables rules. To see ALL the active nftables rules, you can use the command sudo nft list ruleset. To see only rules related to the DEFAULT network, you can specify the table and its family. Table name is libvirt_network, and its family is ip which stands for IPv4 - rules in this table are applicable ONLY to IPv4 network traffic! I prefer to use sudo nft -a list table ip libvirt_network.
The -a option adds a handle to each rule. This handle acts like an index, allowing me to reference and manipulate any specific rule without having to retype the entire rule.

$ sudo nft -a list table ip libvirt_network
...
table ip libvirt_network { # handle 6
    chain forward { # handle 1
        type filter hook forward priority filter; policy accept;
        counter packets 728 bytes 637074 jump guest_cross # handle 7
        counter packets 728 bytes 637074 jump guest_input # handle 5
        counter packets 207 bytes 14639 jump guest_output # handle 3
    }

    chain guest_output { # handle 2
        ip saddr 192.168.122.0/24 iif "virbr0" counter packets 1 bytes 76 accept # handle 55
        iif "virbr0" counter packets 0 bytes 0 reject # handle 52
    }

    chain guest_input { # handle 4
        oif "virbr0" ip daddr 192.168.122.0/24 ct state established,related counter packets 1 bytes 76 accept # handle 56
        oif "virbr0" counter packets 9 bytes 468 reject # handle 53
    }

    chain guest_cross { # handle 6
        iif "virbr0" oif "virbr0" counter packets 0 bytes 0 accept # handle 54
    }

    chain guest_nat { # handle 8
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 0 bytes 0 return # handle 61
        ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return # handle 60
        meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 # handle 59
        meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 1 bytes 76 masquerade to :1024-65535 # handle 58
        ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade # handle 57
    }
}
...

If you’ve already dag all the internet searching for an answer about how to add port forwarding to the DEFAULT libvirt network in NAT mode, or how to use the port forwarding method to access NAT'ed virtual networks, I imagine that your attention is attached to the chain guest_nat in the displayed above libvirt_network table, because it handles NAT.

However, this is misleading! The rule that is actually blocking inbound connections to the VM (deb-mongo, in my case) from a laptop connected to the LAN is not there - the blocking rule is in the chain guest_input!

chain guest_input {
          oif "virbr0" ip daddr 192.168.122.0/24 ct state established,related counter packets 1 bytes 76 accept # handle 56
          oif "virbr0" counter packets 9 bytes 468 reject # handle 53
}

These two rules, #56 and #53, are the culprits behind the issue. Rule #56 accepts ONLY the traffic with destination address in the DEFAULT network 192.168.122.0/24 which is part of ESTABLISHED and RELATED network connections. This is why connections between the host and the VMs work seamlessly, as those are ESTABLISHED or RELATED.
Similarly, outbound traffic from any VM on this network (e.g., downloading packages or connecting to external resources) also falls under this rule.

However, when I try to connect to any VM on this network (192.168.122.0/24) from my laptop, which is on the LAN (a "neighbor" of the host), this traffic is a part of NEW connection. This is where Rule #53 comes into picture and REJECTS any traffic that is part of NEW connections targeting the virtual network devices.

The intuitive solution is to modify rule #56, and using its handle, I can do something like this :

$ sudo nft replace rule libvirt_network guest_input handle 56 oif "virbr0" ip daddr 192.168.122.0/24 ct state new,established,related counter accept

HOWEVER! Remember, it’s wiser to avoid adding overly permissive rules. So, instead, I’ll specify that traffic that is part of NEW connections AND:
A) ONLY from the private IP of my laptop
B) ONLY to the VM deb-mongo
c) ONLY to the port 27017 of the VM deb-mongo
should be accepted, while the rest should fall into rule #53—the rejection rule.

To do this, I need to add a new rule to handle NEW traffic.

Please NOTE! Rule #56, which accepts traffic from ESTABLISHED and RELATED connections, is the first in the chain guest_input. Rule #53, which rejects anything that is not accepted by Rule #56, is the second rule in the chain. If you add a new rule using sudo nft add rule ..., it will be appended to the end of the chain. This means it will never participate in filtering traffic from NEW connections because all these packets will already be rejected by Rule #53. The order of rules in chains matters!

Instead of using sudo nft add rule..., I will use sudo nft insert rule .... This command always inserts the rule at the top of the chain, which is not always ideal for different network logic but, in this case, is completely fine.

$ sudo nft insert rule libvirt_network guest_input \
    oif "virbr0" ip saddr 192.168.1.10 ip daddr 192.168.122.10 tcp dport 27017 \
    ct state new counter accept

VOILA! the connection on my laptop is installed right away after this new rule is added:

As you may notice, if you are following my steps, nothing needs to be restarted with sudo virsh- nor the DEFAULT network, nor the VM, nor the systemd networking service on the host, nor the same service on the VM. That’s the superpower of network traffic management and mangling.

As I mentioned earlier, virbr0 is not connected in any way to any physical network interfaces of your host. All the connectivity is managed through the nftables ruleset in the libvirt_network table for IPv4 traffic.

➂.➄ Considerable drawbacks of this method

In the end, to enable the Port Forwarding on the NAT'ed DEFAULT network it’s just two commands one: to add the firewalld rule to impose port forwarding on the HOST. Second command is to add a rule to the guest_input chain in the libvirt_netwrok ip table in nftables ruleset.

Quite elegant and simple, no? So, what’s the drawback then, besides the complexity of nftables rules for people completely unfamiliar with them? WELL… the drawback is the persistence of this configuration—or, to be more accurate, zero persistence.

When I added the port forwarding rule with firewalld, I noted that I didn’t make it permanent, but you can preserve the rules by using the --permanent option. What about the nftables rule I added? How do you preserve it? No way.

If you remember, at the start, I showed you (using ip link/ip a outputs) that virbr0 doesn’t exist as an interface before you start the DEFAULT network that is based on it. The same logic applies to the nftables rules related to this virtual interface. If you list all the rules when the DEFAULT network is down, there will be no libvirt_network table in nftables ruleset. But the moment you start the DEFAULT network, the table immediately appears—it is added automatically by libvirt itself.

So, any custom rules for the DEFAULT network you add to nftables will be lost the moment this network stops and restarts. This is the main drawback of this otherwise clean and straightforward approach.

There is a workaround, though—a script that can automate the re-adding of the nftables rule. Even though it’s still a workaround, it is presented in the libvirt documentation on how to forward connections for the DEFAULT network.

However, there’s an important note: the documentation’s example is written for iptables, not nftables.

Here’s a tiny reminder: you cannot just drop iptables rules out of the blue on your Debian system if you have nftables up and running. At best, the rules will simply not work. At worst, you will mess up all the network traffic on your host :3.

Here is this script:

#!/bin/bash

# IMPORTANT: Change the "VM NAME" string to match your actual VM Name.
# In order to create rules to other VMs, just duplicate the below block and configure
# it accordingly.
if [ "${1}" = "VM NAME" ]; then

   # Update the following variables to fit your setup
   GUEST_IP=
   GUEST_PORT=
   HOST_PORT=

   if [ "${2}" = "stopped" ] || [ "${2}" = "reconnect" ]; then
    /sbin/iptables -D FORWARD -o virbr0 -p tcp -d $GUEST_IP --dport $GUEST_PORT -j ACCEPT
    /sbin/iptables -t nat -D PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT
   fi
   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then
    /sbin/iptables -I FORWARD -o virbr0 -p tcp -d $GUEST_IP --dport $GUEST_PORT -j ACCEPT
    /sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT
   fi
fi

This workaround is actually a hook script— libvirt's hooks are quite handy for specific system management needs. These hooks can trigger various scripts based on VM-related events like start, shutdown, etc. You can definitely create a similar hook for adding the nftables rule, and it would even be much shorter than this monstrosity of iptables rules.

However, I will not be doing it, nor will I use this configuration for my home lab. That’s because the DEFAULT network is designed for a different purpose—it’s meant to provide a plug-and-play or out-of-the-box experience for new VMs. You create a VM, start it, and everything works from the networking side without additional configuration.

I prefer to keep it that way. For accessibility to the VMs from my LAN devices, I use other network configurations that are better suited for this purpose.

Virtualization on Debian with libvirt&QEMU&KVM — Networking beyond "default": Must Have Concepts to Start

aL — Thu, 23 Jan 2025 00:12:56 +0000

Initially, I planned to publish all how-to s for advanced network configurations for virtual machines in one article. However, I am unstoppable when it comes to writing, and the article became quite long. So, I decided to split the theory from the hands-on configurations, XML/Shell scripting, etc.

You might think you don’t need to read this, but I strongly discourage you from jumping directly to the next article and blindly copying my configurations without understanding what you’re doing.

NB! I’m not a network engineer, nor have I taken courses on this. I’m actually just a dev who’s just passionate about Debian and spends way too much time on my PC. So, please don’t throw slippers at me if I end up sharing any misleading information. I’m simply documenting and describing some of my experiments in this field.

Terminology I will use in this article, sometimes in acronym form – I try to avoid it, but sometimes it just happens automatically:

Host – This refers to your PC, on which you set up virtualization and create virtual machines.
Guest – This is any virtual machine you create. VM/VMs – A virtual machine/Virtual Machines.
ISP – Internet Service Provider.
LAN – Local Area Network.
NAT – Network Address Translation.
DEFAULT network – This refers to the Libvirt's virtual network that virtual machines are connected to by default, within the scope of qemu:///system. If you do not understand the difference between qemu:///system and qemu:///session and how to switch between them, please refer to the previous article. In this article I will be creating/configuring VMs that are in the scope of qemu:///system.
Packet - A network packet is a formatted unit of data carried by a network.

When it comes to networking, it’s really hard to decide where to even start explaining. To avoid turning this article into some kind of networking handbook—which I don’t have the expertise to write anyway—I’ll probably have to skip over some fundamental concepts.

However, I’ll do my best to simplify things and provide schemes for the main concepts so you can (hopefully!) follow along.

Here is the road-map for this article:

➀ About Public IP address and LAN

➀.➀ Inbound vs Outbound traffic

➁ Understanding your LAN and private IP address(s) of your host machine

➁.➀ Network Interfaces: general information
➁.➁ Network Interfaces: MAC addresses
➁.➂ IPv4 vs IPv6 addresses
➁.➃ IPv4 address ranges reserved for private networks
➁.➄ IPv4 addresses structure and CIDR

➂ Libvirt's DEFAULT Network: about NAT mode

➂.➀ About virtual network switches
➂.➁ Libvirt wants iptables, Debian has nftables: what to do?
➂.➂ DEFAULT Libvirt's network: what's under the hood?
➂.➃ Nftables rulesets: tables and chains explained
➂.➄ About how NAT works

Let's start!

I’ve already written some explanations of how your home network works, about public IP address, and ports in this article.

Here is the schematic representation of the most common setup of local "home" network with WiFi router playing the central role in it:

➀ About Public IP address and LAN

The most important takeaway from this scheme is that all your devices—whether they connect to your Wi-Fi router wirelessly or physically (via Ethernet cable)—are part of a local network, your home network. This LAN (Local Area Network) is created and managed by your Wi-Fi router.

Most likely*, only your router has a public IP address! Your devices do not (I wrote most likely because if you’ve configured your Home Lab to use IPv6, the story is quite different. But I’m guessing you wouldn’t be reading this article if you were capable of doing so! :) ) Instead, each device connected to your Wi-Fi network is assigned a private IP address—one private address per device. If, for some reason, something gets messed up with your router and it assigns the same IP address to two devices, those devices will start having problems accessing the internet (they will start losing some packets - for example, pinging will be unstable, with some percentage of packets lost).

You can check your public IP address using website like DNS Leak Test, which will show you IP address with which you visited this site (what is DNS and DNS "leaking" I will explain later in this article). Your Public IP address is discovered by servers hosting the websites you visit. For example, when I upload an image here in articles, the Dev.to servers see the request coming from my public IP address that’s pushing the data.

➀.➀ Inbound vs Outbound traffic

For now, what you know for sure is that a Wi-Fi router is the magic box that allows you to access internet resources from your devices. This is quite obvious because you paid for exactly that. But how does it actually work?

In the previous part of this series, I mentioned that I couldn’t host anything on my PC - a website - without tweaking the router. In general, when someone tries to reach you via your public IP address, they send you packets with some data/requests. These packets first reach your Wi-Fi router as it is the one having public IP address, not your devices connected to WiFi! What happens next depends on your router’s configuration.

Will it drop the packets, effectively blocking them, or will it redirect them to the appropriate member of your local network (for example, your PC)? If it does redirect, the router uses the private IP address (as he knows all the private addresses of connected devices) of the target device (your PC) to forward the packets. Router will also have to forward the packets to the correct port. However, for all of this to happen, the router needs to be explicitly configured. By default, most Home-purpose routers will just block incoming traffic, and the packets will simply be dropped. This is why I cannot host any website on my PC without modifying the configurations of WiFi router.

However, I can download whatever I want by default. When I download something, it comes to my computer in form of packets with data as well. And the stuff that I am downloading is coming in, not out. So, it is also a sort of incoming traffic, and it does not get blocked by WiFi router at all.

The key difference in these two examples is who initializes the communication. When you download something—i.e using wget—it’s your device that sends the request, initializing the connection. The server responds, sends packets with requested data, they arrive to your WiFi router, it redirects them to the device that made a "request" - and that’s why it works - WiFi router does not impede this process, because it is outbound traffic.

Inbound traffic, on the other hand, refers to situations where the connection isn’t initiated by your device—like when uninvited guests show up at the door of your house. In those cases, the firewall rules of your router sends them away. These rules protect your local home network from unexpected or unwanted traffic.

In the scope of this article on virtualization, the focus will be on networking "locally". It won’t be about creating networks that make your VMs publicly accessible, vulnerable, or anything of that sort. I won’t touch my router configurations, and all configurations will be done on networks that operate behind a Wi-Fi router.

➁ Understanding your LAN and private IP address(s) of your host machine

As I mentioned, the Wi-Fi router creates a LAN (local area network). Any devices you connect to the Wi-Fi join this LAN, and their communication—both with each other (if configured so) and with the outside world (web) —is managed by the Wi-Fi router.

The first thing to do is to get familiar with the private IP addresses of your host machine - what do they mean, why they are like this, how to manage them.

If you’re using ONLY Network Manager to handle your network connections... well, put it aside for now. Your new best friend is the iproute2. It should already be installed by default on Debian. The thing is, when you install Network Manager, it can start conflicting with iproute2 configurations. However, on Debian, this is partially resolved by the default setup, where Network Manager only manages wireless network interfaces.

➁.➀ Network Interfaces: general information

Now, let’s take a look at what’s going on with the networks on my host machine.

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> ...
....
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... state UP ....
   ....
3: wlxXXXXXX43643754XX: <BROADCAST,MULTICAST,UP,LOWER_UP> ... state UP 
   ...
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> .... state DOWN ...
    ....

What I have:

lo: This is the loopback interface. It’s a virtual network interface used by my OS to communicate with itself. It’s always there—no need to touch it! It won’t participate in the networking configurations I’ll be covering in this article.

eno1: This is my network interface that comes with the Ethernet cable that physically links my PC to the Wi-Fi router. *This guy will be playing the key role in the networking setups for my VMs.
*

wlxXXXXXX43643754XX: This is the wireless network interface that comes from my USB Wi-Fi adapter. In my setup, it has higher priority - this interface is used for communications with WiFi router and within the LAN. However, this wireless network interface WILL NOT participate in SOME networking setup (bridged networking) for the virtualization process because it’s problematic. Wireless network devices use different drivers, different protocols, and it isn’t trivial to make them to participate in bridged networks.

virbr0: The last guy in the list, which is currently DOWN, is a virtual bridge. It’s managed by libvirt/qemu. It is created when the libvirt daemon is first installed and started. However, it remains down unless any libvirt's network that uses this network interface starts (i.e sudo virsh net-start default).

Let's look into more details about each network interface:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> ...
....
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... state UP ....
   link/ether 12:ab:c3:d4:ef:56
   inet 192.168.1.X/24 brd 192.168.1.255
   inet6 fe80::278e:1234:l678:123/64 
3: wlxXXXXXX43643754XX: <BROADCAST,MULTICAST,UP,LOWER_UP> ... state UP 
   link/ether 98:zy:xb:67:kl:34
   inet 192.168.1.Y/24 brd 192.168.1.255
   inet6 fe80::kre7:b5b5:z8y6:987/64 
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> .... state DOWN ...
    link/ether 77:mo:5g:k9:r0:46
    inet 192.168.122.1/24 brd 192.168.122.255

In this article section, I will explain what are these values: link/ether, inet and inet6.

➁.➁ Network Interfaces: MAC addresses (`link/ether`)

First, I want to point your attention to the fact that eno1 and wlxXXXXXX43643754XX Network Interfaces are providing the connection to the same network, my home local network (LAN), managed by my Wi-Fi router. Just the origin of eno1 is the cable (Ethernet), and the origin of wlxXXXXXX43643754XX is the Wi-Fi USB adapter, so a wireless connection. Why do they have different IP addresses even if they are "attached" to the same network?

All other devices connected to my house Wi-Fi have private IP addresses - like the laptop at 192.168.1.A, the phone at 192.168.1.B, the PlayStation at 192.168.1.C, etc. So why does my single desktop PC have two addresses in the same network? Does this cause confusion?

My PC can connect to a home local network (and to any network that is not virtualized by the PC itself=existing only "inside" the PC) through a NIC—Network Interface Card/Contrtoller. This is a hardware component that is often integrated into the motherboard.

If you’re using a laptop that doesn’t have a port for an Ethernet cable, it most likely doesn’t have a NIC either. So, even if you imagine buying something like a USB-to-Lightning-to-Type-C adapter just to connect an Ethernet cable to port of Type C, it won’t work. This is because it’s not just about the "shape" of the cable, but the capability to process the type of communication that comes through it - and this capability is granted by NIC.

The solution is to purchase a proper USB hub with a built-in NIC and Ethernet port. The laptop example is a good one because it shows that an Ethernet cable is not the cornerstone of connectivity to networks. Such laptops indeed connect wirelessly, if a network of interest allows so. In this case, they do not use a default NIC but rather a WNIC—a Wireless Network Interface Card.

A WNIC in a desktop computer often needs to be purchased separately—either as a PCIe network card (to be attached to the motherboard's PCI slot) or as part of a USB Wi-Fi adapter.

In my case, I have them both, integrated NIC and WNIC of WiFi USB adapter:

#list of Ethernet controllers
$ lspci | grep -i ethernet
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Controller
#list of WNIC
$ lsusb
Bus 002 Device 002: ID 1234:5678 TP-Link 802.11ac NIC

My Wi-Fi router perceives connection from each (W)NICs as a separate initialization of a connection and assigns a distinct private IP address to each. That’s why my PC, which has two network interfaces, ends up with two IP addresses—one for each (W)NIC. The router cannot identify that both NICs physically belong to the same device (my PC) because the physical identifiers are the NICs themselves (not a CPU, not a motherboard ecc)!

Each NIC has its own unique MAC address (Media Access Control address), which serves as the unique permanent identifier. Not only network interfaces, but every piece of network-connected hardware, MUST HAVE a unique MAC address in a network. This is different from an IP address because a MAC address is permanent: every NIC has one and only one MAC address, hardcoded by the manufacturer (though, sometimes it is possible to change it). You can see the MAC addresses of your network interfaces using ip link or ip a commands—in the lines labeled link/ether.

While MAC addresses are permanent, an IP address is temporary and can change quite often - every time a device connects to a network, it is possible that WiFi router can assign to it a new private IP address (the probability of it depends on the network configuration and the device’s own settings).

You can think of a MAC address as a device’s permanent name, while an IP address is more like instructions for other devices on how to communicate with it. For example, your device might always be MAC number A, but at any given moment, it can be located at IP address B or IP Address C ecc.

Now that I’ve covered MAC addresses, it’s time to explain IP addresses.

➁.➂ IPv4 vs IPv6 addresses and NAT

To see the IP addresses of your PC's network interface(s) (roughly speaking Private IP address(es) of your PC) you can execute ip a command. You can scroll up and take another look at my output of this command. Now you know that the link/ether field tells you the MAC address(es) of network interfaces. If you’re familiar with IP addresses, you can guess that inet field exactly contains IP address information (the address though which other devices on the same network can communicate with PC). However, 'inet' field is not the one that shows you IP address of a network interface. inet6 field (if you have it) shows you another address and it is also IP address (even if it looks more like a MAC address)!

My PC's eno1 interface (Ethernet) has inet 192.168.1.X/24 and inet6 fe80::278e:1234:l678:123/64; wlxXXXXXX43643754XX interface (wireless) has inet 192.168.1.Y/24 and inet6 fe80::kre7:b5b5:z8y6:987/64; virbr0 virtual network interface managed by libvirt has only inet 192.168.122.1/24.

Both inet and inet6 fields of ip a output contain completely valid IP addresses - it’s not like what you see in inet6 field is just an encrypted, altered, or transformed version of inet field value, nor does it indicate a completely different network. The value of inet field is the IPv4 address, while inet6 displays the IPv6 address.

IP stands for Internet Protocol and it has two major versions: IPv4 and IPv6. IPv6 is the newer, more advanced version, offering enhanced features, greater capabilities, and significant potential for addressing future network demands.

In a previous article, I already touched on the topic of IPv4 vs. IPv6 differences. I’ll share the most relevant takeaway as it relates to this article:

A unique public IP address is a scarce resource! Actually, a unique public IPv4 address is in deficit. Internet Protocol version 4 (IPv4) forms the foundation of most Global Internet traffic today. An IP Address represented under IPv4 is composed of four sets of numbers ranging from 0 to 255, separated by periods(.).
If you do the straightforward math - total four numbers in an IPv4 address; each number can be in range between 0 and 255 (256 possible values) - 256 * 256 * 256 * 256 = 4,294,967,296 total addresses.

The first distinction is that IPv6 addresses are not just numerical; they are alphanumeric. IPv6 can provide many more unique addresses than the IPv4 system (340 trillion trillion trillion unique addresses vs 4 billion). But this is not the only difference. IPv6, as a protocol, is more modern and from the beginning was designed to be more secure.

It is not like IPv4 was designed without security in mind, just when it was created, the internet had far fewer users, and the number of devices worldwide was significantly lower. Let me illustrate how it affects the security mechanisms.

Security mechanisms, such as encryption, inevitably introduce additional computational load. For example, imagine my PC is communicating with your PC using an encryption mechanism. All the packets we exchange are heavily encrypted, and our devices communicate using public IP addresses, which act like the destination addresses for our data packets (like mailing letters). My device with its public IP address communicates with your device at its public IP address.

This scenario demonstrates the end-to-end principle of communication: my device can communicate with yours securely, with security mechanisms implemented directly in the communicating end nodes (our PCs, that have encryption/decryption keys). The intermediary nodes (like gateways and routers) don’t take part in our secure communication.

So, the Gateways and Routers are bad? Not at all! However, in this example, gateways and routers can A) introduce computational overhead B) make some encryption mechanisms impossible.

Getting closer to the topic... This idealized scenario of end-to-end communication is possible today, but only if we use IPv6 and our devices are properly configured to support it. Why? Because IPv6 adreesses poll is really huuuge, so every device can have a public IPv6 address, enabling direct communication between them without needing intermediary translation.

Each packet that we exchange in my example as any network packet consists of control information (headers) and user data (payload). Control information provides data for delivering the payload (e.g., source and destination network addresses, error detection codes, or sequencing information).

So, in case of IPv4. My PC sends to my WiFi router a packet that it is meant for you. But my PC does not have a Public IP address! So the source IP address in the headers is abracadabra for the web scope and it needs to be_ translated_, according to some rules. This job is done by NAT - Network Address Translation mechanism of my WiFi router. And here it is why this intermediary node in our communication is a baddie - NAT introduces processing overhead because it rewrites packet headers for every packet that passes through the router. And this happens not only on my side, but also on your side!

Some encryption techniques are meant for end-to-end communication only with consistent IP addresses - so they are not possible if NAT (in its default form) is in the middle.

With IPv4, gateways, routers become unavoidable due to the scarcity of public IPv4 addresses, and so does NAT. I started introducing NAT right here; however, I will elaborate more on this in the next sections, as the libvirt's DEFAULT network is based on the NAT mechanism.

_A little thought experiment: how do you think the internet would be if IPv6 were fully adopted and replaced IPv4? What would happen to the prices for internet service? Would the speed of the internet change? PS. you can check out what is CGNAT :) _

In this article, I will use IPv4 addresses for any network configuration. Unfortunately, Internet Protocol version 4 (IPv4) still forms the foundation of most global internet traffic today. Plus, as I stated earlier, this article is focused on creating a local network rather than configuring any VM to be remotely reachable from the outside.

The scope of IPv4 reserved addresses for private networks is quite large for a home setup, so let's move to it.

➁.➃ IPv4 address ranges reserved for private networks

According to standards set forth in Internet Engineering Task Force (IETF) document RFC-1918 , the following IPv4 address ranges are reserved by the IANA for private internets, and are not publicly routable on the global internet:
10.0.0.0/8 IP addresses: 10.0.0.0 – 10.255.255.255
172.16.0.0/12 IP addresses: 172.16.0.0 – 172.31.255.255
192.168.0.0/16 IP addresses: 192.168.0.0 – 192.168.255.255
Note that only a portion of the “172” and the “192” address ranges are designated for private use. The remaining addresses are considered “public,” and thus are routable on the global Internet.(Source)

Key takeaway is that there is set of IPv4 IP addresses that are reserved for private networks. The reservation ensures that there will be no conflicts with global - public IP addresses.

➁.➄ IPv4 addresses structure and CIDR

All IPv4 IP addresses has the same structure - 4 numbers divided by dots: x.x.x.x. The trailing slash with a number after it is not a part of IP address, it is CIDR (Classless Inter-Domain Routing) notation.

Take a detailed look at this again:

10.0.0.0/8 IP addresses: 10.0.0.0 – 10.255.255.255
172.16.0.0/12 IP addresses: 172.16.0.0 – 172.31.255.255
192.168.0.0/16 IP addresses: 192.168.0.0 – 192.168.255.255

The largest network range (with the most IP addresses) is represented by 10.0.0.0/8. The CIDR number after the slash (e.g., "/8") is not random; it refers to the number of bits allocated for the network portion of the IP address.

A "/8" means that the first 8 bits are reserved for the network, leaving 24 bits for the host part. This allows for 16,777,216 available addresses for devices (hosts) within the network. The smaller the CIDR number (like "/8"), the larger the number of available IP addresses, because fewer bits are used for the network portion, and more are left for devices.

The IP IPv4 address is 32 bits long, divided into four groups (octets) of 8 bits each. For example, 192.168.1.0 is written as:

192    .    168    .     1    .    0
11000000.10101000.00000001.00000000

Each number is an 8-bit block (each block represents one of the four octets). The CIDR prefix tells how many of these 32 bits are used for the network portion.

Lets return to my outputs from ip a:

eno1: inet 192.168.1.X/24 brd 192.168.1.255
wlxXXXXXX43643754XX: inet 192.168.1.Y/24 brd 192.168.1.255
virbr0: inet 192.168.122.1/24 brd 192.168.122.255

eno1 and wlxXXXXXX43643754XX network interfaces connect my PC to the local network managed by my WiFi router. Router assigned them private IP address 192.168.1.X and 192.168.1.Y. These IP addresses were vacant, so they were assigned by router's DHCP (Dynamic Host Configuration Protocol). CIDR /24 tells me that in this local network there are 256 "spots" for devices:

/24 means the first 24 bits are for the network. This leaves 8 bits for the host (the devices within the network). Network bits: 24 bits; host bits: 8 bits; 2^8 = 256 possible IP addresses in this network (but in practice, some are reserved for special purposes).

The virbr0 network interface is a different case. First, it is managed by libvirt/QEMU, as I mentioned, not by my WiFi router, and it is a virtual bridge. The Network to which this network interface connects also has a CIDR of /24, meaning there are 256 available addresses.

However, remember the last information I shared in the previous part of this series on virtualization? RECAP: I created a VM connected to the DEFAULT network, and I mentioned that even though it can reach the internet, no device connected to my local home network can access this VM via SSH, ping, or anything else (except HOST!). This is because any 192.168.122.X address is not part of my local home's 192.168.1.X/24 network! The 192.168.1.X/24 range covers addresses from 192.168.1.0 to 192.168.1.255, but any 192.168.122.X address is outside of that range. As a result, there’s no connection, no communication.

After this long introductory session, let’s get back to virtualization with virsh, QEMU, and KVM, focusing on network configurations.

➂ Libvirt's DEFAULT Network: about NAT mode

libvirt uses the concept of a virtual network switch. The network interface you saw in my ip a outputs in the previous section, called virbr0, is nothing more than a virtual network switch automatically created and managed by libvirt.

➂.➀ About virtual network switches

I don’t know if you’re familiar with physical network switches, but these guys look like this (not so friendly for trypophobic folks, hehe):

Getting closer to understanding networks: my PC has an Ethernet cable that’s plugged into the Wi-Fi router. But what if I plug it into my laptop instead? Haha, I can’t do that because my laptop doesn’t have an Ethernet port. However, if I could, that connection would create a small network of two devices (my PC and my laptop), allowing them to communicate with each other.

But what if I wanted to attach something else—a second laptop? It would be pretty hard to do with the scarcity of Ethernet ports (even if both laptops had one Ethernet port).

If I had a network switch, though, I could plug in all the devices I wanted—up to the number of available ports on the switch. The network switch would handle the communication between them by forwarding packets between connected devices!

So, the virtual network switch works kinda the same way, just for VMs. The default virbr0 virtual network switch is used when VMs are connect to the DEFAULT network. This virtual network switch enables them to communicate easily with each other.

Here is the DEFAULT network:

$ sudo virsh net-list --all

 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   no          yes

This DEFAULT network operates in Network Address Translation (NAT) mode (the one I introduced above discussing IPv4 vs IPv6).

By default, a virtual network switch operates in NAT mode (using IP masquerading rather than SNAT or DNAT).
This means any guests connected through it, use the host IP address for communication to the outside world. Computers external to the host can't initiate communications to the guests inside, when the virtual network switch is operating in NAT mode. (Libvirt: Virtual Networking)

DEFAULT network in the NAT modeLibvirt documentation

Libvirt's documentation specifies, that the NAT is set up using iptables rules.

And here we arrive at another important player in the whole networking process – iptables. It is often perceived juts as a tool that protects your system from unauthorized access/traffic based on some rules. However, the reality is that it is much, much more than that, as it can also be used for traffic manipulation, forwarding, NAT (Network Address Translation), and more.

Iptables provides packet filtering, network address translation (NAT) and other packet mangling.
NOTE: iptables was replaced by nftables starting in Debian 10 Buster. (Debian Wiki: iptables)

I am using Debian Sid, so I definitely have nftables and not the legacy iptables.

Is nftables just a modern version of iptables with fixed vulnerabilities, faster performance, and so on, but still it is just theiptables under the hood? NO. They are two different frameworks designed to do the same job—'mangling' network traffic. However, think of 'different frameworks' in this context as you would if you have experience with Python: it's like TensorFlow and PyTorch. In web development, it's like React and Angular. You cannot write a neural network using PyTorch and then expect to just copy-paste the network source code into TensorFlow and have it work. The same goes for nftables and iptables. They are different, with different syntax, and different logic, especially when it comes to IPv6 traffic.

It's better not to mix the two, thinking, 'Oh, for an issue Y I'll write and add some rules in iptables, but then for the issue X I found a tutorial for nftables, so I'll add rules this way'. (Played Witcher 3? Remember what happened to Geralt when he was courting both Triss and Yennefer? Well, the same can happen to your network traffic if you start playing around with different tools for network traffic management)

However, even if you do so (use both the nftables and the legacy iptables tool at the same time), Debian has you covered in a certain way. First, the iptables utility is not installed on the system by default. If it is installed, the iptables utility will, by default, use the nftables backend. But, again:

Should I mix nftables and iptables/ebtables/arptables rulesets?
No, unless you know what you are doing. (Debian Wiki: nftables)

➂.➁ Libvirt wants `iptables`, Debian has `nftables`: what to do?

As I mentioned before, libvirt's DEFAULT network functions in NAT mode, and this NAT mode is defined using iptables rules. So, when you installed libvirt tools, it most probably pulled in iptables as a dependency. Indeed:

$ aptitude why iptables
i   libvirt-daemon-system          Depends libvirt-daemon-driver-nwfilter (= 10.10.0-3)
i A libvirt-daemon-driver-nwfilter Depends iptables

But I already discouraged you from using iptables, hehe. So, what's the plan? First, most likely, you don't even have nftables up and running yet :D. Because if you did, and it was running as a systemd service, you would have encountered some troubles starting VMs with the DEFAULT network. I'll show you why:

#if for some reason you do not have nftables installed:
# $ sudo apt install nftables
$ sudo systemctl status nftables
#is it active? No? Then, start it
$ sudo systemctl startnftables
# and ENABLE it so it will start on the Boot
$ sudo systemctl enable nftables.service

FYI: Take a look at the nftables ruleset "in use" using command sudo nft list ruleset when nftables.service is stopped and when it's started (or before starting it and after). Compare the two and try to find libvirt's NAT configuration :).

#And now I bring UP DEFAULt libvirt network
$ sudo virsh net-start default
error: Failed to start network default
error: internal error: Failed to apply firewall command 'nft -ae insert rule ip libvirt_network guest_output iif virbr0 counter reject': Error: Could not process rule: No such file or directory
insert rule ip libvirt_network guest_output iif virbr0 counter reject

OOPS! I broke everything. Libvirt wants iptables, not nftables.
Whatever wants Libvirt, but in Russian there is saying: "eat what is given". There’s a legit solution to make libvirt work well with nftables. And it’s not just some workaround.

Maybe you are familiar with UFW—Uncomplicated Firewall—this tool is built on top of iptables, making it easier to manage iptables rules. You write simplified rules, and it translates them into iptables rules in the underground. A similar interface also exists for nftables! It’s called firewalld.

First, let’s clarify why this isn’t just a workaround that adds extra software to your system just to make something work for VMs:"

You should consider using a wrapper instead of writing your own firewalling scripts. It is recommended to run firewalld, which integrates pretty well into the system. See also https://firewalld.org/ (Debian Wiki: nftables)

And...:

The firewalld software takes control of all the firewalling setup in your system, so you don't have to know all the details of what is happening in the underground. There are many other system components that can integrate with firewalld, like NetworkManager, libvirt, podman, fail2ban, docker, etc.(Debian Wiki: nftables)

So, firewalld, besides all its perks in firewall configuration and network traffic management, is the bro that will make libvirt function correctly with nftables. It will ensure that all the NAT rules, written with love by the libvirt devs, are active. That means the DEFAULT network based on NAT rules will work again.

$ sudo apt install firewalld
$ sudo systemctl start firewalld
$ sudo systemctl enable firewalld

#have a look on the new ruleset firewalld brought with it to nftables
$ sudo nft list ruleset

What about libvirt's ruleset for NAT?

$ sudo nft list ruleset | grep libvirt

#nothing 

#now i start DEFAULT network
$ sudo virsh net-start default
Network default started
$ sudo nft list ruleset | grep libvirt
        iifname "virbr0" jump mangle_PRE_libvirt
        iifname "virbr0" jump nat_PRE_libvirt
        iifname "virbr0" oifname "virbr0" jump nat_POST_libvirt
...

$ sudo nft list tables

table inet filter
table inet firewalld
table ip libvirt_network
table ip6 libvirt_network

So, there's a separate "table" for libvirt_network. This table is managed by libvirt, and libvirt fills this table with rules when its virtual network switch becomes active (virbr0). This happens only if at least one network using the virtual bridge virbr0 is started.

➂.➂ DEFAULT Libvirt's network: what's under the hood?

As I mentioned before, the libvirt DEFAULT network's NAT is set up using iptables rules. And in my case Libvirt is forced to use what is available on my Debian - nftables. So, if I explore existing rules in nftables, I for sure should find there Libvirt's default network rules, according to which traffic circulate between VMs and FROM VMs TO the "outside world".

And here's how the network magic happens for VMs: when they interact with each other and with the host, and access the internet to fetch whatever they're commanded to:

$ sudo nft -a list ruleset
table ip libvirt_network { # handle 6
    chain forward { # handle 1
        type filter hook forward priority filter; policy accept;
        counter packets 0 bytes 0 jump guest_cross # handle 7
        counter packets 0 bytes 0 jump guest_input # handle 5
        counter packets 0 bytes 0 jump guest_output # handle 3
    }

    chain guest_output { # handle 2
        ip saddr 192.168.122.0/24 iif "virbr0" counter packets 0 bytes 0 accept # handle 13
        iif "virbr0" counter packets 0 bytes 0 reject # handle 10
    }

    chain guest_input { # handle 4
        oif "virbr0" ip daddr 192.168.122.0/24 ct state established,related counter packets 0 bytes 0 accept # handle 14
        oif "virbr0" counter packets 0 bytes 0 reject # handle 11
    }

    chain guest_cross { # handle 6
        iif "virbr0" oif "virbr0" counter packets 0 bytes 0 accept # handle 12
    }

    chain guest_nat { # handle 8
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 1 bytes 40 return # handle 21
        ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return # handle 20
        meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 # handle 19
        meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 # handle 18
        ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade # handle 17
    }
}

➂.➃ Nftables rulesets: Libvirt Network's table and chains explained

Let’s break it down:

First, libvirt_network rules have their own table. In nftables, tables act as "containers" within the overall ruleset (to see the full list: sudo nft list ruleset). Tables contain chains, sets, maps, flowtables, and stateful objects.

Each table belongs to exactly one family. If you want to apply a specific set of rules to some network traffic, you must first define the table by specifying its type. The type determines that only traffic of this specific type will be filtered by the rules in that table.

For example, the table ip libvirt_network rules only filter IPv4 traffic/packets because its table is assigned the ip family:

table ip libvirt_network

A chain is essentially a list of rules. In the case of libvirt_network ruleset, everything starts with the forward chain, which is responsible for filtering incoming traffic packets.

table ip libvirt_network {
    chain forward { #rules}
        chain guest_output {#rules}
    chain guest_input {#rules}
        chain guest_cross {#rules}
    chain guest_nat {#rules}
}

  ______         A |-----------------|F
 |packet|  --->  C |  chain forward  |I ---|
  ¯¯¯¯¯¯         C |  type: filter   |L    | 
                 E |  hook: forward  |T    |
                 P |  policy: accept |E    |
                 T |-----------------|R    |
                     -----packet---->      | 
                                           |
                                Routing decision:
                     <---?---  | |----?----> 
             |-----------------| | -----------------|
             |                 | ?                  |
|------------------------|     | |    |------------------------| 
|    chain guest_input   |     | V    |   chain guest_output   |    
|    inbound packets     |     |      |    outbound packets    |
|   destined for guests  |     |      |       from guests      |   
|           ?            |     |      |             ?          |
|------------------------|     |      |------------------------| 
            |                  |                    |  
|-----------|------------|     |      |-------------|----------|  
|                        |     |      |                        | 
+ACCEPT             REJECT-    |      +ACCEPT             REJECT-
+If:              Anything-    |      +If:              Anything-
+outgoing             else-    |      +source IP:           else-
+interface:               -    |      +192.168.122.0/24         -
+virbr0                   -    |      +                         - 
+                         -    |      +incoming                 -
+connection               -    |      +interface:               -
+state:                   -    |      +virbr0                   -     
+established OR           -    |      +++++++++++++++++++++++++++ 
+related                  -    | 
+                         -    |      |--------------------------|
+destination:             -    |      |    chain guest_cross     | 
+in 192.168.122.0/24      -    |------|    traffic between       |
+++++++++++++++++++++++++++           |    guests on virbr0      |                                            
                                      |             ?            |        
                                      |--------------------------| 
                                      +ACCEPT              REJECT-
                                      +If:                No rule-
                                      +incoming interface:       -
                                      +virbr0                    - 
                                      +                          - 
                                      +outgoing interface:       -
                                      +virbr0                    -
                                      ++++++++++++++++++++++++++++ 

 ##########################################################  
 #                Routing decision is made!               #
 #                            IF:                         #
 #                 outbound packets from guests           #
 ##########################################################
    :==========:      ______                      :==========:
    :guest VM  : --> |packet|                     : Other VM : 
    :==========:      ¯¯¯¯¯¯                      :==========:
                        |                                  ^ 
                        V                                  |
 |------------------------|    |--IF traffic FROM:      NO NAT
 |                        |    |                    (NO masquerade)
 |   chain guest_nat      |--->| guest subnet TO:          ^
 |   type: nat            |    | (224.0.0.0/24) OR --------|
 |   hook: postrouting    |    | (255.255.255.255)
 |   priority: srcnat;    |    |==================================
 |   policy: accept;      |--->| IF traffic FROM:   
 |                        |    | guest subnet TO: ---------|
 | -----------------------|    | DIFFERENT subnet          V
                               |           MASQUERADE traffic (NAT)
                                                           |
                                          INTERNET <--------

I hope this ASCII scheme brought some clarity to how VMs attached to the DEFAULT libvirt's network communicate with the host, with each other, and with the outside world. Here’s some more info.

A network packet pops up on the virbr0 interface and then gets filtered (by chain forward) and routed or dropped - based on the nftables rules.

For example, when one VM sends a packet to another VM (if both are connected to DEFAULT network, it’s routed to that VM. The rules in chain guest_cross are triggered—there’s no rejection, so the packet is delivered without any special mangling, since it goes from virbr0 to virbr0 network interface. Chain guest_nat also participates, but NAT does not apply here because it’s an internal connection, and the rules say that when it’s from the same subnet to the same subnet, there’s no NAT.

Another example: the host sends a packet to a VM. This triggers the chain guest_input. The connection tracking state is established in this case (the VM has already initiated a connection to the host). And here it is! This is why you cannot connect to the VM remotely (even from another device connected to the same local home network as host and configured port forwarding!)—it will be new connection, not established!

Also, if you try to connect to the VM from a laptop on the same Wi-Fi as the host, it gets dropped because the VM is on a different network (remember, 192.168.122.x is not a part of 192.168.1.0/24 network!). But you configured port forwarding? Still nope. Packets will be dropped. Because again, it’s a new connection.

Yet another example: the VM wants to run sudo apt update && sudo apt upgrade. It needs to fetch data from the Debian repositories. This is governed by chain guest_output, so the rules are triggered and they don’t cause the drop of packets. Then the guest_nat chain is activated because traffic is going from the guest subnet to an external subnet. Without NAT, it wouldn’t work at all—the VM network is different from your local home network (WiFi), so they don’t directly communicate. They’re isolated from each other, and virbr0 doesn’t bridge these two networks!

To summarize: there are only two possible outcomes for the network traffic you initialize - FROM and TO your virtual machines that are attached to the DEFAULT network—it will either reach its destination (ACCEPTED) or be dropped (REJECTED).

I hope it’s clear when it comes to host-to-VM, VM-to-host traffic, and communication between VMs. 1) There are no specific nftables network filtering/mangling rules blocking it. 2) These communications are possible by the specifically configured and virtualized virbr0 virtual network switch.

However, HOW does traffic TO the internet—and especially FROM other networks (like your home LAN) work — can still be challenging to understand. NAT (Network Address Translation) might still appear like a black box. So, in the final section of this article, I’ll try to simplify things and explain it in detail.

Understanding NAT is crucial for all IPv4 traffic, as NAT has become a widespread networking configuration. This is due to the inherent limitations IPv4 faces in the modern world, making NAT a kind of symbiotic solution for IPv4 networks.

➂.➄ About how NAT works

Let’s get back to the NAT chain of the libvirt_network ip table. This chain doesn’t just apply filtering rules to network traffic—it handles postrouting rules, meaning it sees all packets after routing, right before they leave the local system.

For example, imagine your VM wants to connect to the internet to update itself when you run sudo apt update. This command fetches the data about the versions of your system’s packages against the repository versions. The packets from the VM are sent to http://deb.debian.org/debian/ (the Debian package repo source link).

These packets (fetching request) end up on virbr0, which acts like an airport for them. It decides if these “passengers” (packets) need to take an “international flight” (outside the guest VM network) or a “domestic flight” (within the guest VM network).

NB! I will cover DNS servers and gateways that act as routers in detail in the next article! For now, let’s simplify things (even though it’s not fully technically accurate) and say that the virbr0 virtual network switch handles this somehow, so I can focus on explaining NAT (otherwise I will never finish this article T_T).

Let's get back to the postrouting rules specified in the guest_nat chain and disaamble them to see how they worl

$ sudo nft -a list ruleset
...
chain guest_nat { # handle 8
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 1 bytes 40 return # handle 21
        ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return # handle 20
        meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 # handle 19
        meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 # handle 18
        ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade # handle 17
    }
}
..

Handles are used natively by nftables to make it easier to reference specific rules when you need to modify or transform them, so they’re quite handy for me right now—I don’t have to retype rules.

Handles #20 and #21 aren’t what I’m looking for to illustrate NAT in action. These handles specifically ignore packets traveling within the same guest network.

But handles #19, #18, and #17 are exactly where NAT is in action! These three handles are categorized based on the communication protocol in use—TCP (#19), UDP (#18), and all other protocols (#17).

All three handles process traffic in the same way. The key word in all these rules is masquerade.

The term masquerade hints what happens to the source address of the network traffic—it gets "masked".

Let’s follow the network packets from a VM that executed sudo apt update. First, since network communication of this type uses the TCP protocol, I have to look into the rule of handle #19:

ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 -->  
--> This is like a programming `if` condition:
If the **s**ource **addr**ess (saddr) is within the 192.168.122.0/24 subnet 
AND the **d**estination **addr**ess (daddr) is outside of this subnet:
     masquerade to :1024-65535

Masquerade replaces the original source address with something else. In this case, it replaces it with the private IP address of the host. More specifically, it replace it with the private IP of the network interface with the highest priority (if there’s more than one, as in your case).

And what’s with the numbers after the colon? Those are ports—specifically the ephemeral port range (1024-65535). Why such a big range? And aren’t these ports busy on the host?

This port range is the ephemeral port range, which is designed to avoid conflicts with privileged ports (0–1023). Privileged ports are reserved for well-known system services, so this range ensures the masqueraded traffic doesn’t interfere with them.

Oh I left alone the packets from sudo apt update. Here they are: after masquerading:

The packets originally departed from the VM at 192.168.122.10 on port 80 (since it’s HTTP traffic)
They reached virbr0 (the virtual network switch).
virbr0 routed them to go outside the DEFAULT network (where VM belongs to).
Before leaving, they were masqueraded: each packet’s header was modified: the source address was replaced from 192.168.122.10:80 → to 192.168.1.5:12345. Here, 192.168.1.5 is the private IP address of the host (my PC), and 12345 is an ephemeral port assigned dynamically for this communication.

Here is the peculiar schema:

Source of Original Image

And that’s how NAT works. That’s all. Hahaha, just kidding.

That’s how the FIRST NAT worked. Now, these poor little packets have to "embark" on yet another "plane". They’re off to their next layover, where they’ll get NAT'd (masqueraded) AGAIN— new masks for everyone! This time, the layover is at the WiFi router.

The NAT’d packets leave the host with source address 192.168.1.5:12345. They arrive to my Wi-Fi router on the LAN side.
Wi-Fi Router NAT

The WiFi router sees packets from 192.168.1.5:1234 → to 123.123.7.132:80 (I am sooo bad, I do not know the IP address of Debian Servers & lazy to check).

NAT rewrites the source IP AGAIN from 192.168.1.5 to my router’s public IP (111.111.111.111) and change the port to another ephemeral one (54321).

NB! This is important! This is the cornerstone of weak routers (from the point of hardware):

Network packets don’t just travel to the Debian servers for a one-way trip; it’s always a round trip! At some point, response packets will come back. In the case of success, the VM expects to receive information about the versions of the packages it requested, to figure out what’s outdated.

Now, with all this masquerading, we end up in a situation much like those in movies—a classic masquerade ball drama (someone gets kissed because they were mistaken for someone else under their mask). To prevent these kinds of situationships, the WiFi router steps in as the responsible dude in charge. The router keeps track of who is going where, and if something comes back from "there," it makes sure it gets sent to the right who. To do this, router keeps updated a sort of table (thankfully it’s .xlsx). This table looks something like this:

|Private IP    | Public IP      | Source Port | Destination Port |
|192.168.1.5   | 123.193.7.162  | 54321       | 80               |
|192.168.1.20  | 111.153.6.132  | 35465       | 443              |
|192.168.1.11  | 125.161.7.162  | 34564       | 27017            |
|192.168.1.16  | 3.193.5.132    | 1224        | 22               |
.......................
#This table can be quite long if many devices are connected to the same WiFi and actively use Internet!

And then, the router keeps this information... in the table.

Here’s where an important point comes in: this table can grow very quickly. If your router is fast and powerful, no big deal—but if you cheaped out on it, you might run into trouble. A router that can’t handle more than a certain number of rows (based on its hardware limitations) will start to slow down significantly as the table grows beyond.

Again I left alone travelling network packets. Here they are:

The packets departed to the Debian server with my public IP and an ephemeral port: 111.111.111.111:54321.

The Debian server responds, and the response arrives from 123.123.7.132:80 to the router. The router then checks its table and says, "Ah, here it is!" It finds the matching entry in its tracking table and figures out which device the response is meant for. At this point, the router rewrites the headers of the packet AGAIN, removing its public IP address (111.111.111.111) and restoring the private IP and port from the table. Finally, it sends the packet back to my PC (the host) at 192.168.1.5:12345.

The host sees in the packets the destination 192.168.1.5:12345, checks its NAT table from the guest_nat chain, and recognizes this was originally from 192.168.122.10:80.

It rewrites AGAIN the destination from 192.168.1.5:12345 back to the VM’s IP and port: 192.168.122.10:80.

The packet is finally forwarded to the VM at 192.168.122.10:80.
The VM sees a response from http://deb.debian.org/debian/ to 192.168.122.10:80, completes the TCP handshake, and gets the repository data.

And now, that’s truly that's all! This is how NAT works. Enjoying IPv4? Still thinking IPv6 is difficult and scary?

For a little fun (and for little support for my emotional state after writing this article), try counting and writing in the comments how many times the network packets from the VM, headed to the internet, were rewritten along the way :).

Now after this TINY introduction to networking, it is time to get to the hands-on configurations. How can I make virtual machines accessible from other devices connected to the same LAN as the host—or even remotely? While I won’t be covering remote access here, making VMs accessible from other devices on the same home network can be quite convenient.

For example, I have a pretty powerful Desktop PC in terms of specs, and maybe sometimes I’m lazy and want to work from my laptop, which is like a toy in comparison to my PC. When I say I am lazy, I mean I don't want to sit properly at my desk; I want to loaf on the sofa with my laptop. However, I still want to use the resources of my PC. I can, of course, connect via SSH to my host machine, but it may be that I just want to connect to the VM with MongoDB to do something or check on it.

There are three main ways to do so:

Port forwarding & Custom NAT
Bridged networking (aka "shared physical device")
PCI Passthrough of host network devices

All of them I will cover in the next article.

Virtualization on Debian with virsh&QEMU&KVM — Installation of virtualization tools and first VM creation

aL — Sun, 12 Jan 2025 13:00:56 +0000

In this article, I will not cover the basics of virtualization—what it is and when you might need it. This article is for those who are more or less familiar with the concept, but don’t know how to get started with it on Debian.

Here’s the road map for this article:

➀ Virtualization and self-hosting
➁ Virtualization as a tool for resource-Constrained application development
➂ Virtualization on Debian: how it works

➂.➀ CPU virtualization support
➂.➁ Hypervisor

➃ KVM & QEMU
➄ Libvirt
➅ Validation of virtualization tools installation

➅.➀ Important! qemu:///system vs qemu:///session

➆ Creation of first VM:

➆.➀ OS image file
➆.➁ Preparing storage
➆.➂ VM creation with virt-install

➇ Let the Networking begin!

➇.➀ Userspace (SLIRP or passt) connection
➇.➁ NAT forwarding (aka "virtual networks")

First, I will introduce my use case - why do I need virtual machines on my personal PC.

Long story short, I’m an "on-premise" girl (read "not very pro with cloud infrastructures"). I have an experience with dealing with on-prem infrastructure, and now I’m facing the need to deploy SOMEWHERE my personal project—a web app—so it sees the real world and real world sees it. And no, this isn’t a static website; it has a backend and a database. And hypothetically, some components will need horizontal scaling in the future.

➀ Virtualization and self-hosting

My personal PC isn’t bad at all in terms of specs—perfectly capable for development purposes and even, theoretically, for serving all the needs of my small app in production. However, hosting anything exposed to the web on a personal PC is out of the question. If your first thought is that the only obstacle is my PC needing to run 24/7, it is not about it. Using a machine that has some personal data for hosting of something exposed to the web is a VERY BAD IDEA. If you don’t understand why, you can check out this article.

If I create Virtual Machine(s) on my personal machine, and configure very well the networks, does that solve the problem? NO! And here’s why. The main impediment to hosting anything from "home"—even if you bought a proper server for it—is your router and internet provider. Is this about internet speed? Nope. It’s about...your public IP address.

Let's say you move into a new house, and it doesn’t have Wi-Fi. So you contact the internet providers in your city, check the prices, select the most advantageous offer, and… sign the contract. If you’re just an average user and didn’t specify otherwise, the contract gives you “internet for your house” from the chosen provider.

A technician arrives at the scheduled appointment, brings some cables, and a plastic box—which is the router. They deal with the cables, connect them to the router, hand you a manual along with the Wi-Fi network name and password, and voilà! You can connect all your home devices and enjoy browsing the web.

When you just use the internet, you’re most likely never even aware of your public IP address. But chances are, it’s not static at all. It changes periodically, and this is done by your internet provider—because that’s how they often manage their clients with “home” use.

When it comes to hosting something, like a website, even if you buy a domain name like my-cool-site.it, how will people find it? Who will bind YOUR PC WITH CODE of this site (where all the site’s needs and dependencies reside) to that domain? Domain name of your web app needs to be resolved in such a way that the correct IP address behind it is revealed.

Theoretically, you don’t even need to buy a domain name; your site can work perfectly fine with just an IP address like https://12.34.56.78/home. But it’s not a top if you want your site to be searchable on Google and not just accessible by people who already have the link.

If your internet provider changes your public IP address periodically, it’s like frequently moving houses. People trying to send you letters would still send them to your old address unless you keep updating them, and the letters would never reach you. The same logic applies to the hosting having a dynamic IP. You could, of course, manually update everything and rebind the domain to your new public IP address, but that’s hardly convenient.

If you want to have a static public IP address, you should contact your internet provider and find out the conditions under which you can get it. It will probably come with an increased payment for internet service. Is sticking a certain IP address to your Wi-Fi router that hard and does it require extra effort to keep it like this to cover "technical" costs? No. The increased payment is not even very related to the fact that the need for fixed public IP address can hint that the internet access is for business use, so it’s about earning something, and therefore why not to charge you more. Well... it’s because a unique public IP address is a scarce resource! Actually, a unique public IPv4 address is in deficit. Internet Protocol version 4 (IPv4) forms the foundation of most Global Internet traffic today. An IP Address represented under IPv4 is composed of four sets of numbers ranging from 0 to 255, separated by periods(.).

If you do the straightforward math - total four numbers in an IPv4 address; each number can be in range between 0 and 255 (256 possible values) - 256 * 256 * 256 * 256 = 4,294,967,296 total addresses.

So here, on the market for internet service, a basic economic rule comes into play: demand is growing with increasing digitalization around the world, but the supply is restricted by the very nature (mathematical) of the good (unique IPv4 address), so the prices for this good are increasing. In the next article, I will cover more details on IPv4, explain a bit about IPv6 (the solution for this IP deficit situationship), and also cover some interesting aspects of networking that are consequences of this IPv4 address deficit (NAT).

Plus, another obstacle for self-hosting is a router, provided by your internet provider. They often have very restricting measures in terms of incoming https/s traffic (it gets blocked), and those restrictions (thankfully) will impede any hosting attempts. I say thankfully, because if you truly do not understand how it works, it is better that these restriction, firewall rules, are up and protecting you.

However, keep in mind, hosting on the **same network **you use for any personal device is not a perfect idea if you are unable to configure all the security mechanisms, firewalls, and configure networks properly.

Summing this up, currently, it is not an option for me to "selfhost".

➁ Virtualization as a tool for resource-Constrained application development

So, virtualization is not a solution for my problem with deployment of the web-app. Then where it can be deployed? The cloud. I can choose a cloud provider, rent the instances that match my app's needs, configure them, and deploy my app. Simple, right? Well, not so fast—because every instance, every service, comes with a price. And those prices... For someone like me, who’s built a pretty powerful PC for around $1,000, seeing cloud pricing for "little server" instances can be a bit confusing. To give you an idea, you can explore pricing on AWS using their calculator. I’ll share some screenshots of EC2 instance pricing:

2 vCPUs, 4 GB of RAM, and storage for an additional cost. All yours for around $30 per month if you want to host something that has a server side operations.

Actually, 2 vCPUs, not CPUs. vCPUs stand for virtual CPUs because they aren’t real physical CPUs—they’re virtualized. And an EC2 instances are essentially just virtual machines.

Now as we are back to the word virtualization, let’s talk about my use case—my needs. When it comes to the development of my app on my PC, even though I could install everything needed directly (since I’m always using the same stack as a developer), it’s far from optimal. Why clutter my PC with installations os stuff like Nginx and MongoDB, leaving them hanging around unnecessarily when the project is finished?

To keep everything tidy for development purposes, virtual machines hosted on my PC is the great solution. However, the real issue with development directly on my PC is this: when I develop on a machine with 20 CPU cores of the latest generation, 64 GB of RAM, and 12 GB of GPU memory, how can I be sure that what I’ve developed will actually run on a small EC2 instances? Or more importantly, how can I evaluate the resource requirements for my app in general? (let's leave code-based evaluation aside for now)

This is where virtualization will really help me. I can evaluate my code’s performance right from the start by creating VMs with small resources attached and placing my app's components there!

Note for the Dockerists/Dockerphiles/Containerphiles

I can already foresee the "Gosh, just learn Docker—it’s easy! Developing on bare metal is dinosauric; containerization is the key!" argument. I have no doubt Docker can handle everything. In fact, I personally enjoy Docker Swarm quite a bit (can’t say the same for Kubernetes, though).

However, let’s not forget that Docker has under a virtualization technology. And as I mentioned earlier, EC2 instances are nothing more than virtual machines. So, when you spin up an EC2 instance, you’re essentially getting a VM—a virtual layer. Then, when you install Docker on top of that, you’re adding… yet another virtual layer! And all of this is happening on a modest machine with just a few CPUs and some RAM.

You know what happens when you pile on more and more virtualization layers? They take you farther and farther away from the bare-metal performance of the hardware.

And Kubernetes for small apps? That’s like using a bazooka to kill a fly. Sure, I know Docker apps can be deployed in various ways on AWS (not only on top of EC2), but that’s not the point. My small-scope web app doesn’t need any of the "perks" Docker van bring.

"with Docker, my app can run everywhere"—because it’s no longer tied to OS. But I don’t plan to run my app anywhere except on Debian. I know how my app component's VMs work; I will set them up myself and I will know exactly what’s there.
"Docker provides an isolated environment" Sure, but isolated from what? Separate VMs already provide plenty of isolation.

As for bundling and isolating software of different components, and managing version conflicts. If it is your primary need for Docker even in small projects...Naughty, naughty - did you give up on pure TypeScript/Python and relied on external libraries a lot? Not my case, by the way.

Why would one follow the containerization hype just because everyone else is doing it?

That said, I’m not completely throwing Docker out of my stack. But for me, dockerization is something I’ll consider only when everything else is ready.

Moreover, Docker/Containerization is as same easy as virtualization/Virtual Machines. Different sintaxis, some different concepts, but the logic behind is more or less the same. Docker is easy when it comes to setting up everything in a default way, but if you need something more advanced, most probably you will get very frustrated if you do not know anything about virtualization of hardware and virtual machines. Docker is not a rocket science at all for those who have some experience with Virtual Machines.

So let's start with virtualization on Debian!

➂ Virtualization on Debian: how it works

Virtualization process is happening under the "instructions" of your PC's physical CPU, so it is important that your CPU is supporting it. Yes, virtual machines can access (if allowed so) various hardware components of your PC, but it is exactly the CPU that is responsible for isolation of process running on guest VMs from the host (your physical PC). If your CPU supports the virtualization, first, it needs to be enabled on your PC:

➂.➀ CPU virtualization support

To know if you have virtualization support enabled, you can check if the relevant flag is enabled with grep. If the following command for your processor returns some text, you already have virtualization support enabled:
For Intel processors you can execute grep vmx /proc/cpuinfo to check for Intel's Virtual Machine Extensions.
For AMD processors you can execute grep svm /proc/cpuinfo to check for AMD's Secure Virtual Machine. (The Debian Administrator's Handbook: Virtualization)

In my case:

#this command is counting the number of times 'vmx flags' is mentioned in the output of /proc/cpuinfo. It is equal to 20, meaning that all my CPU cores support virtualization (I have 20 cores totale)
$ egrep -c '(vmx flags)' /proc/cpuinfo
20
#additional command
$ lscpu | grep Virtualization
Virtualization:       VT-x

If in your case the output of command grep vmx /proc/cpuinfo is empty, but your CPU is quite modern and is supposed to support virtualization, you’ll have to enter the BIOS during boot and enable it there. The steps to follow in BIOS are something like described in this guide. The interface of your BIOS depends on the brand of your motherboard, so if you are lost you’ll need to check instructions on how to enable virtualization on your PC in web.

All the CPU cores are ready to virtualize something! Who starts?

➂.➁ Hypervisor

A hypervisor! hypervisor is a bit generic term:

A hypervisor, also known as a virtual machine monitor (VMM) or virtualizer, is a type of computer software, firmware or hardware that creates and runs virtual machines. A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine. (Wikipedia)

There are different types of hypervisors. To simplify their perception, they can be divided into two types (left and right images of the scheme below):

The second type of hypervisors might be familiar to you if you’ve ever used VirtualBox. It runs on top on Windows, just like any other app on Windows. On the other hand, Type 1 hypervisors run directly on bare metal. They often have their own OS, specifically tuned for virtualization purposes. And they are often used for enterprise scope.

I included Proxmox in the category of hypervisors type 2, because it comes as a Debian-based OS. To use it, you’ll need to replace your current desktop Debian with Proxmox OS. By the way, Proxmox is pretty great—easy to use and functionality-rich. I use this hypervisor for work, and I find it awesome. But it is not fully technically correct that Proxmox is hypervisor of type 1, as it is based on KVM&QEMU.

Let's get to KVM, that is schematized in the middle on the image above. Is it a hypervisor? Well... yes and no. The term "hypervisor" is generic, so you could call it that. But technically, KVM is a Linux kernel module. You don’t have to build it yourself—it comes shipped with the Linux kernel that is core part of your Debian, just like other kernel modules (for example, drivers).

In this article, I’ll be using KVM to set up virtualization tools on my PC. A popular alternative to KVM on Debian is Xen. Xen is a truly Type 1 hypervisor, even though it can also run alongside Debian OS for personal use.

Xen is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. (The Debian Administrator's Handbook: Virtualization)

As Xen runs between the hardware and the upper systems it qualifies as a Type 1 hypervisor. VMware ESXi is another example of a Type 1 hypervisor.

I’ll be using a KVM-based virtualization setup instead of Xen—just a personal preference.

➃ KVM & QEMU

But what exactly is KVM, besides being a kernel module?

The Kernel Virtual Machine, or KVM, is a full virtualization solution for Linux on x86 (64-bit included) and ARM hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, which provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. (Debian Wiki: KVM)

While KVM is providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application.
Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors.
Unlike such tools as VirtualBox, KVM itself doesn't include any user-interface for creating and managing virtual machines.(The Debian Administrator's Handbook: Virtualization)

Before, I showed how to check if the virtualization is enabled on your PC, the following command will show you if you have KVM kernel module and it can be used:

# checking for presence of KVM kernel modules
$ lsmod | grep kvm
kvm_intel             327680  0
kvm                   983040  1 kvm_intel
#Additional check with cpu-checker package:
$ sudo apt install cpu-checker 
$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

As the Debian Manual on virtualization stated in the quote above KVM alone goes alongside with qemu for virualization porocesses.

QEMU (stands for Quick Emulator) is a generic and open source machine emulator and virtualizer.
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.
When used as a virtualizer, QEMU achieves near native performance by executing the guest code directly on the host CPU. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, 64-bit POWER, S390, 32-bit and 64-bit ARM, and MIPS guests. (QEMU Wiki)

Is it possible to virtualize using only KVM? THEORETICALLY yes, but KVM has neither GUI nor CLI, so one has to write code in C in order to virtualize something, but KVM alone will not emulate virtual CPUs or virtual RAM.
Can you use QEMU without KVM? Yes. QEMU alone can emulate a full system with its built-in binary translator Tiny Code Generator (TCG), which is purely emulated (= compute-intensive) and overall performance of fully emulated system can be slow. Thus, using QEMU without an accelerator is inefficient and generally best for experimental purposes (e.g if your CPU has an architecture A, but you’re curious about exploring how it all works on CPU architecture B). To “accelerate” the emulated system that run on the same architecture to the host’s one QEMU is using accelerators; and KVM is one of them. However, QEMU can use alternative accelerators like XEN (QEMU: Virtualisation Accelerators).

QEMU is not a software package that comes pre-installed on Debian, so you’ll need to install it manually. And here’s where confusion can arise. If you Google around, you’ll most likely find something like this for Debian-based systems sudo apt install qemu-kvm virt-manager bridge-utils. At first glance, this seems fine— you actually need QEMU to work with KVM. But here’s the tricky part: qemu-kvm isn’t even a real package. It’s a virtual package, which actually point to something else:

For my case, it’s fine because I plan to have all my guests using this architecture. But if you want to use a different architecture for your guest VMs, qemu-kvmwill bring in redundant package. There are other packages that will install QEMU besides qemu-system-x86, like qemu-system-arm, qemu-system-misc, qemu-system-ppc and qemu-system, which will bring you dependencies to virtualize/emulate various architectures with qemu.

I will install QEMU in this way:

$ sudo apt install qemu-system-x86

To shape your choice a bit, according to QEMU documentation on virtualization with KVM:

QEMU can make use of KVM when running a target architecture that is the same as the host architecture. For instance, when running qemu-system-x86 on an x86 compatible processor, you can take advantage of the KVM acceleration — giving you benefit for your host and your guest system (QEMU: features KVM)

Technically, if you try to create a guest with a CPU architecture different from your host machine’s CPU, KVM won’t be used, because, remember, QEMU can fully emulate machines (I haven’t tested this myself, though).

QEMU is installed, KVM is ready to virtualize, so everything is technically set up. However, the QEMU CLI syntax is far from simple and pretty particular. I would prefer to use a syntax which is more familiar to me. And this is where Libvirt will help me.

➄ Libvirt

Libvirt is collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management.
An primary goal of libvirt is to provide a single way to manage multiple different virtualization providers/hypervisors. No need to learn the hypervisor specific tools! (Libvirt FAQ)

Libvirt is a bundle of software that includes an API library, a daemon (libvirtd), and a command line utility (virsh).

Libvirt tools for management of virtual machines are 'virsh', 'virt-manager', and 'virt-install', which are all built around libvirt functionality.

virt-manager is a GUI tool for creation and management of VMs entirely through a graphical user interface (GUI) <-- can be a viable option in the beginning.
virt-install is a CLI tool that enables the creation and management of VMs via commands and parameters. If created VMs are supposed to have a display and graphical sessions, they can be accessed with virt-viewer (for a display).
virsh is a command-line utility that can do a lot of stuff - staring from very simple tasks like VM creation up to advanced virtualization. virsh works tightly with XML configuration files, that can be used to configure domains, virtual machine specs, networks ecc. Virsh gives an option to connect to existing VMs remotely via SSH <--I will be using this tool.

I install libvirt with the following command:

$ sudo apt install libvirt-daemon-system
$ systemctl status libvirtd
● libvirtd.service - libvirt legacy monolithic daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-01-10 22:39:29 CET; 2min 17s ago
#if not enabled in your case:
# $ sudo systemctl enable libvirtd

In this way, I will have libvirt-clients installed as well, as it is a dependency of this package.

Everything needed is supposed to be installed for now. First, I want to validate that everything is OK, and then I can proceed with first VM creation.

➅ Validation of installed virtualization tools

$ virt-host-validate
  QEMU: Checking for hardware virtualization  : PASS
  QEMU: Checking if device '/dev/kvm' exists  : PASS
  QEMU: Checking if device '/dev/kvm' is accessible : PASS
  ...
$ virsh version
Compiled against library: libvirt 10.10.0
Using library: libvirt 10.10.0
Using API: QEMU 10.10.0
Running hypervisor: QEMU 9.2.0

#command to check, which guest machines you can emulate with QEMU features you have installed:
$ virsh capabilities
...
  <guest>
    <os_type>hvm</os_type>
    <arch name='i686'> <---
      <wordsize>32</wordsize> <---
      <emulator>/usr/bin/qemu-system-i386</emulator>
      ...
      <domain type='qemu'/> <---
      <domain type='kvm'/>  <---
    </arch>
  </guest>

  <guest>
    <os_type>hvm</os_type>
    <arch name='x86_64'> <---
      <wordsize>64</wordsize> <---
      <emulator>/usr/bin/qemu-system-x86_64</emulator>
      ...
      <domain type='qemu'/> <---
      <domain type='kvm'/>  <---
    </arch>
  </guest>

➅.➀ Important! qemu:///system vs qemu:///session

Here is the command I want you to pay attention to:

$ virsh uri
qemu:///session

$ sudo virsh uri
qemu:///system

As you can see, there’s a difference between running virsh with sudo or without it. When you run virsh with sudo, it connects to the system libvirtd service, the one launched by systemd. libvirtd is running as root, so has access to all host resources. Daemon config is in /etc/libvirt, VM logs and other bits are stored in /var/lib/libvirt.
On the contrary, if you run virsh without sudo, it connects to qemu:///session, that is a session libvirtd service running as the app user, the daemon is auto-launched if it's not already running. libvirt and all VMs run as the user. All config and logs and disk images are stored in $HOME directory of a user. This means each user has their own qemu:///session VMs, separate from all other users. Details are taken from here.

If, for some reason, your output of virsh uri is empty, you can connect manually. And if you mess up between the session or system, you’ll be informed about it in the output.

$ virsh
virsh # connect qemu:///system
==== AUTHENTICATING FOR org.libvirt.unix.manage ====
System policy prevents management of local virtualized systems

#The correct way if you want to connect to user-space session:
virsh # connect qemu:///session
#The correct way if you want to connect to system wide session:
$ sudo virsh
virsh # connect qemu:///system

THIS INFO IS VERY IMPORTANT:

With qemu:///session, libvirtd and VMs run as your unprivileged user. This integrates better with desktop use cases since permissions aren't an issue, no root password is required, and each user has their own separate pool of VMs.
However because nothing in the chain is privileged, any VM setup tasks that need host admin privileges aren't an option. Unfortunately this includes most general purpose networking options.
The default qemu network mode when running unprivleged is usermode networking (or SLIRP). This is an IP stack implemented in userspace. This has many drawbacks: the VM can not easily be accessed by the outside world, the VM can talk to the outside world but only over a limited number of networking protocols, and it's very slow. (Source)

If this quote does not tell you much, here is the key takeaway: qemu:///session integrates better with desktop use cases. Any VM setup tasks that need host admin privileges aren't an option. This means that your VMs in the scope of qemu:///session will have ONLY general purpose networking options.

➆ Creation of first VM

NB! For the demonstration purposes, I will be creating first VM in the scope of qemu:///session. In this way, I will be able to demonstrate the constraints of created VM. Then, I will show you, how to move create VM under qemu:///system.

➆.➀ OS image file

To create my first virtual machine, which will, of course, be Debian Stable (Bookworm), I need an .iso file. I’ll go for the minimal netinstall image to keep the system tidy and install later only tools I will need.

$ cd #to teleport to $HOME directory
$ mkdir -p .local/share/libvirt/images/
$ cd .local/share/libvirt/images/
$ wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.9.0-amd64-netinst.iso

➆.➁ Preparing storage

Then, I want to specify the storage device I plan to use for all my virtual machines (as they will share portions of it). Since I manage all storage devices on my PC using LVM, the first step is to create a new logical volume using the available free space in my existing logical volume group.

$ sudo vgs
  VG            #PV #LV #SN Attr   VSize    VFree
  MY-vg       1   5   0 wz--n- <372.53g <129.02g

How will my virtual machines use the storage space I plan to create for them? Each machine will have one or more virtual disks, and these virtual disks are essentially "disk images." As everything is a file on Linux OS, these disk images are files. And they can have different formats. The .qcow format is a file format for disk image files used by QEMU. Its updated version, .qcow2, offers better optimization to the original .qcow. I can also create disk images for VMs in the .raw format. However, .qcow2 is generally more space-efficient and can be snapshot-ed and compressed.

So the task is the following: I need to create a .qcow2 disk image for my to be created VM. And I want to use available space in my logical volume group.

There are two options:

I can create a fairly large new logical volume to provide space for multiple virtual machines. In this case, I need to place a file system on top of the new logical volume, mount it, and then create .qcow2 disk images over it. Why? Because a logical volume without a file system is a single, contiguous block of storage. A single .qcow2 can occupy the entire block device, but there’s no mechanism to store multiple files on the same device unless a file system is present.
The second option is to create separate logical volumes sized to the needs of each virtual machine, with each logical volume fully allocated to a single .qcow2 image. By the way, you can also use physical partitions for your VMs, as logical volumes are just my preferred method of managing storage space. However, even if under each .qcow2 image there is its "personal" logical volume, this doesn’t mean you can expand the size of .qcow2 image by expanding
logical volume. No, not at all. If my VM runs out of space, I’ll need to attach a new "virtual disk", create an additional logical volume, create new .qcow2 image over it.... This quickly becomes a mess.

So, I prefer the first option: a single logical volume as a kind of storage pool for all my virtual machines disk images.

If your understanding of LVM terminology is a bit wobbly and you still confuse logical volume groups with logical volumes, I recommend to read this article.

#I create new logical volume with name 'virt-machines' inside of the existing volume group
$ sudo lvcreate -L 100G -n virt-machines MY-vg
# I create filesystem on top of it 
$ sudo mkfs.ext4 /dev/MY-vg/virt-machines
# I create a mounting point for it
$ sudo mkdir -p /mnt/virt-machines
# I mount it
$ sudo mount /dev/MY-vg/virt-machines /mnt/virt-machines
# i add automounting option on boot with by modifying /etc/fstab
$ sudo vim.tiny /etc/fstab
# I add this line 
/dev/mapper/MY--vg-virt--machines /mnt/virt-machines ext4 defaults 0 0
# to validate syntax:
$ sudo mount -a

Now, I can create a .qcow2 disk image in this directory. Since I plan to create and run VMs in my user space, I’ve given ownership of this directory to my user to avoid any permission issues later.

# I create a .qcow2 disk image
$ sudo qemu-img create -f qcow2 /mnt/virt-machines/deb-nginx.qcow2 10G

I have an .iso file from which the VM will boot (which will be attached as a virtual CDROM), and I have a virtual disk where the new system will be installed. Now, I just need to create a VM and allocate CPU cores and RAM to it. For the first VM creation, I will use virt-install instead of virsh to demonstrate the logic, and then proceed with XML configuration explanations. The virt-install CLI is part of the virtinst package and is not included in the libvirt-clients package. It needs to be installed separately.

➆.➂ VM creation with `virt-install`

I will be using the default options of the virt-install command, with two exceptions: --graphics none and --extra-args='console=ttyS0'. My VMs don’t need any graphical interface as they will not have display servers; I will access them via the console. Debian offers not only a graphical installer but also a terminal user interface (TUI) installer, which will guide through the installation process.

$ sudo apt install virtinst
$ virt-install \
  --connect qemu:///session \
  --name deb-nginx \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/mnt/virt-machines/deb-nginx.qcow2,size=10 \
  --location $HOME/.local/share/libvirt/images/debian-12.8.iso \
  --os-variant debian12 \
  --graphics none \
  --extra-args='console=ttyS0'

If you encounter an error:

Traceback (most recent call last):
  File "/usr/bin/virt-install", line 6, in <module>
    from virtinst import virtinstall
  File "/usr/share/virt-manager/virtinst/__init__.py", line 8, in <module>
    import gi
ModuleNotFoundError: No module named 'gi'

Check if you are currently not in any active Python environment. I use anaconda, so the base conda environment is always activated. I just deactivate it with conda deactivate command before executing virt-install command.
You will see this:

And then installation of Debian (in TUI only) should pop up.

After installation is finished, VM is rebooted, I close active console ad reconnect with virsh.

$ virsh --connect qemu:///session console deb-nginx

Actually, everything is ready, VM is usable, so technically I can try to go into SSH...

➇ Let the Networking begin!

To SSH into the VM, I need to know the private IP address it was assigned (and I believe it was, as I expect some default network to have been configured and the VM joined it during the creation process via QEMU). I will leave the details about how SSH works from a networking perspective for now and will cover it in the next article of this virtualization series.

To find out IP of created VM:

root@deb-nginx:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu qdisc noqueue state UNKNOWN 
....
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether MA:CA:DD:RE:SS:VM brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp1s0
       valid_lft 77570sec preferred_lft 77570sec
    inet6 XXXXXXXXXXXXXX/64 scope site dynamic mngtmpaddr
       valid_lft 86291sec preferred_lft 14291sec
    inet6 XXXXXXXXXXXXXXXX/64 scope link
       valid_lft forever preferred_lft forever

The network interface is enp1s0, and the IPv4 address is 10.0.2.15. So, let's try ssh!

#from Host machine!
$ ssh 10.0.2.15

Nothing!

➇.➀ Userspace (SLIRP or passt) connection

However, as I mentioned earlier, qemu:///session VMs are primarily intended for desktop use, such as trying out a new distro. The network used under qemu:///session is somewhat primitive and restrictive—it does not allow incoming connections to the VMs and cannot be properly modified. For instance, you cannot configure more sophisticated network settings without sudo privileges to create network components like bridges, change their states, etc.

I can check which network is configured for this VM, and in general, I can review the full configuration of created VM. When I used virt-install, I simply passed some options during the creation process to specify how I wanted my VM, and those parameters were translated into configuration file. This file is much more detailed and "technical" than the option list I provided when I was creating VM. QEMU thoroughly translated my requirements into technical specifications, allocated the necessary hardware, and configured other components for my VM to work. The configuration format used by virsh for almost everything is XML.

$ virsh dumpxml deb-nginx

<domain type='kvm' id='3'>
  <name>deb-nginx</name>
  <uuid>0057aa74-392a-4b4b-ac89-8557d7b9312d</uuid>
  ...
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu> <--interesting
  <os>
    <type arch='x86_64' machine='pc-q35-9.2'>hvm</type>
  </os>
  <features>
   ...
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'/> <--interesting
   ...
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' discard='unmap'/>
      <source file='/mnt/virt-machines/deb-nginx.qcow2' index='2'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <alias name='sata0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    ....
--------------> HERE IT IS, NETWORK INTERFACE <-------------------
    <interface type='user'>
      <mac address='MA:CA:DD:RE:SS:VM'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    ....
 ---> O! Mouse and keyboard: <---------
    <input type='mouse' bus='ps2'>
      <alias name='input0'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input1'/>
    </input>
    ....
</domain>

Created VM has a network interface, only one. But in XML configuration file I see that this interface has type "user" <interface type='user'>, and normally the type should be "network".

I can check for existing alternatives (other network interfaces). Under qemu:///session, as expected, there is nothing:

$ virsh net-list --all

 Name   State   Autostart   Persistent
----------------------------------------

However, it seems that this userspace network thingy can now be configured quite extensively, because newer versions of libvirt have introduced more advanced features and options:

Since 9.0.0 an alternate backend implementation of the user interface type can be selected by setting the interface's subelement type attribute to passt. In this case, the passt transport (https://passt.top) is used. Similar to SLIRP, passt has an internal DHCP server that provides a requesting guest with one ipv4 and one ipv6 address; it then uses userspace proxies and a separate network namespace to provide outgoing UDP/TCP/ICMP sessions, and optionally redirect incoming traffic destined for the host toward the guest instead.(Libvirt: Userspace connection

However, configuration of userspace connection is beyond the scope of this article (and the next article on networking as well). For my use case, I don’t actually need port forwarding—I need something different.

➇.➁ NAT forwarding (aka "virtual networks")

However, qemu:///system has one default interface (NAT):

 $ sudo virsh net-list --all

 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   no          yes

So, I just recreate a VM into qemu:///system scope and this VM will be using by default this 'default' network.

First, I have to destroy and undefine VM in qemu:///session.

$ virsh destroy deb-nginx
$ virsh undefine deb-nginx
#(optionally, recreare disk image)
$ sudo rm /mnt/virt-machines/deb-nginx.qcow2
$ sudo qemu-img create -f qcow2 /mnt/virt-machines/deb-nginx.qcow2 10G
#IMPORTANT! Start dafault network if it is not started yet
$ sudo virsh net-start default

$ sudo virt-install \
  --connect qemu:///system \
  --name test \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/mnt/virt-machines/deb-nginx.qcow2,size=10 \
  --location /var/lib/libvirt/images/debian-12.9.iso \
  --os-variant debian12 --graphics none \
--extra-args='console=ttyS0'

Please note where I placed the ISO file. If you place it inside /etc/libvirt/in some folder, as it might seem like the right place, you could encounter a weird and misleading error, such as:
error: internal error cannot load AppArmor profile 'libvirt-9cb01efc-ed3b-ff8e-4de5-7227d311dd15'.

If you put the ISO file somewhere under your $HOME directory, you might see a warning like this:
WARNING /home/..../debian-12.8.iso may not be accessible by the hypervisor. You will need to grant the 'libvirt-qemu' user search permissions for the following directories: ['/home/...', '/home/....local', '/home/.../.local/share'].

Both errors are related to the fact that the VM creation process cannot access the ISO file.

Meanwhile I proceed with new Installation via TUI. I setup LVM on this VM, and I put /var on separate logical volume, because this VM is meant for NGINX and NGINX can be very talkative in its logs, especially if configured badly. If you do not know how to do it, refer to this article. I also installed SSH server, so I can ssh into this VM from host.

NB if you have ufw up! During installation, Debian should auto-configure the network. If it fails and you see this:

...disable ufw temporarily for the process of installation, then enable it again afterward. It's not the best solution, the best approach is to adjust ufw rules so it doesn't block DHCP requests and DNS resolution, which libvirt uses to configure the VM's network through the default NAT setup.

When Installation is completed, I reopen the console with virsh and login into the freshly created VM. First, lets I check connectivity, disccover the IP address, try to ssh from host:

$ sudo virsh console deb-nginx
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=15.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=16.3 ms
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP>
.....
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether XXXXXXXXXXXXXXXX brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.125/24 brd 192.168.122.255 scope global dynamic enp1s0
       valid_lft 3217sec preferred_lft 3217sec
    inet6 XXXXXXXXXXXXXXXX scope link
       valid_lft forever preferred_lft forever

So, the IP is 192.168.122.125.
*NB! If you try to execute ssh 192.168.122.125 from the host, the login will fail because you will automatically be attempting to ssh as root, and root login via ssh is disabled by default on Debian.
*

I do:

$ ssh user@192.168.122.125
->yes
user@192.168.122.125's password:

So, what can I do from this VM from the network standpoint:

I can access the Internet (e.g., run apt update and apt upgrade).
I can SSH into this VM from the host machine.

What I cannot do:

I have a laptop connected to the same home network as my PC (via WiFi). Can I SSH into this VM from the laptop? No. This is why:

$ ip a
.....
5. virbr0 ...
  inet 192.168.122.0/24

You may have many questions and few answers about network configuration, but this article is already quite long, so I’ll move the networking setups to the second part of this series

Debian 12 … is amazing! How to: Create your custom codehouse #6 [Giving Voice to Debian: Wireless Audio Devices configuration]

aL — Mon, 30 Dec 2024 12:34:07 +0000

In the previous article, I demonstrated all the steps required to set up a custom UI from scratch, including the display server, window manager, status bar and additional useful apps. Additionally, I shared my choices for fundamental apps, such as a terminal emulator and a browser.

Now, it’s time to complete the setup. What I configured previously was primarily focused on output devices—like the monitor, which handles what you see—and input devices like the keyboard and mouse, which allow interaction with applications. However, input and output audio devices remain untouched (in my case, a Marshall wireless Bluetooth headset with both a microphone for input and speakers for output).

My input/output audio device is only one—a Marshall IV headset (which I use mostly in wireless Bluetooth mode, but it also has a wired option). I don’t have separate speakers or a microphone. So, the first thing I need to ensure is that my Bluetooth dongle is working properly. I have written a detailed article dedicated to troubleshooting Wi-Fi and Bluetooth devices, so if your Bluetooth device gives you any troubles, please refer to that article.

My Bluetooth dongle works perfectly on Debian—truly plug and play. There’s no need for configuration, installation of drivers/firmware, or any tweaks; it just works. This Bluetooth dongle is from the brand Edimax, purchased on Amazon for around $10 (Edimax BT-8500). It supports the Bluetooth 5.0 protocol.

Therefore, my Debian system is ready to be configured to use my headset seamlessly for audio playback and, if needed, microphone input.

Here’s the road map for this article:

➀ Sound on your PC: where it starts (hardware-side)?

➁ Sound on your PC: where it starts (software-side)?

➂ ALSA, PipeWire or Pulseaudio: what is better*? (*trick question)

➃ Bluetooth devices management tool

➄ PipeWire vs Pulseaudio

➅ PipeWire: Installation

➆ About XDG Desktop Portal

➇ Pipewire audio profiles: Understanding the difference between device profile headset-head-unit and a2dp

➀ Sound on your PC: where it starts?

Let’s start by understanding what is the crucial component of your PC which determines whether you can enjoy any audio or not. It’s not just about having speakers/microphone, a headset, or anything else that can actually play/register sound. Your PC needs a hardware piece capable of processing audio at a very low level. That job is done by sound cards.

A sound card is a computer expansion card that can input and output sound under program control. (Source)

If you have a laptop or a PC—or if you built a PC manually and you are worried that you might have forgotten some piece—there’s nothing to worry about in 99% of cases; your machine has a sound card. Modern machines typically have on-board sound cards integrated into the motherboard.

Zoomed area of sound card on motherboard with 3 audio jacks

Depending on your motherboard’s specifications, the quality of the integrated sound card will vary, and that directly affects the quality of the sound your PC can produce or record. Some people who work with professional audio may find the capacities of integrated sound cards unsatisfactory, so they might opt for an additional sound card that can be attached via PCIe or USB (not all motherboards have PCIe slots for sound cards, though). However, for everyday use, an integrated sound card is usually very sufficient.

$ lspci -d ::0403 #::0403 here means Audio device subclass
00:1f.3 Audio device: Intel Corporation Raptor Lake High Definition Audio Controller (rev 11)
01:00.1 Audio device: NVIDIA Corporation GA106 High Definition Audio Controller (rev a1)

The first audio device is my motherboard’s integrated sound card. But what about NVIDIA Corporation High Definition Audio Controller? Why is it there? Can I use it?

Nvidia High Definition Audio allows NVIDIA GPU to transmit audio to any display (monitor or TV) with built-in speakers, provided it has an audio-capable connector (most commonly HDMI or DisplayPort). By using Nvidia HD Audio, you can enjoy various uncompressed and lossless audio formats, which can significantly enhance your overall listening experience—especially if you’re using modern displays with integrated speakers.

However, my monitor is pretty simple and it does not have any audio device. So, I will be using on-board soundcard.

➁ Sound on your PC: where it starts (software-side)?

As with any hardware device, a sound card needs firmware and drivers to function. On Debian, you usually don’t have to worry about these, except in cases where something is messed up with the kernel modules—this can often happen if Debian is running on a virtual machine. Yes, like most drivers, sound card drivers are part of Linux kernel, so it’s the Linux kernel that provides them to your Debian.

$ lspci -k -d ::0403
00:1f.3 Audio device: Intel Corporation Raptor Lake High Definition Audio Controller (rev 11)
    DeviceName: Intel HD Audio
    Subsystem: ASUSTeK Computer Inc. Raptor Lake High Definition Audio Controller
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel, snd_soc_avs, snd_sof_pci_intel_tgl
01:00.1 Audio device: NVIDIA Corporation GA106 High Definition Audio Controller (rev a1)
    Subsystem: ASUSTeK Computer Inc. GA106 High Definition Audio Controller
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel

Everything is alright with sound card's driver in my case - snd_hda_intel driver is present and in use.

➂ ALSA, PipeWire or Pulseaudio: what is better*? (trick question)

I have a sound card, I have drivers and firmware, and I have an audio output device—my headset connected via cable (let’s leave aside the Bluetooth management part for now).

So, I go to YouTube to listen to my favourite music band, Public Memory...

Well, I can’t hear anything (I can’t provide a screenshot as proof, though XD). So, what am I missing?

If you’ve ever Googled/troubleshooted about audio on Linux, most probably you’ve encountered the three names ALSA, PulseAudio, and PipeWire, regardless of your distro. Maybe, these names can be confusing. Are they alternatives to each other, do you need all of them, or which one is better? That’s why I gave this section its title. I want to answer these questions by exploring why I can’t listen to Public Memory - which software I am missing?

ALSA (Advanced Linux Sound Architecture)

_ Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.
Put simply, ALSA can be divided into two components: The kernel API that provides access to your sound card for higher-level sound servers and applications, and a userspace library that provides more general functions (like effects, mixing, routing, etc.)
There is no way to "replace" ALSA, with regards to the kernel API. Previously, there was also OSS (Open Sound System), but that's been deprecated for nearly 20 years. The same is not true of ALSA's userspace library, which can be replaced. (Debian Wiki: ALSA)_

Here we are! The first answer is: ALSA is a must-have. No ALSA = no audio. Moreover, you already have it on Debian, because it is the part of the Linux kernel, the same as sound card drivers. So, since I have the Linux kernel, I should already have ALSA installed.

Indeed, I have it:

# I check for presense of package that contains the ALSA userspace library and its standard plugins, as well as the required configuration files:
$ dpkg -l | grep libasound2
ii  libasound2:amd64                     1.2.8-1+b1                           amd64        shared library for ALSA applications
ii  libasound2-data                      1.2.8-1                              all          Configuration files and profiles for ALSA drivers

Why I cannot listen to Public Memory, then?? T-T.

Well, if you haven’t been reading this series of articles from the first part, you might not know that when I installed my Debian, I used a super minimal installation: Debian Stable with only the standard system utilities. This setup is usually perfect for server environments, and the last thing you’d typically do on a server is play music. So, I do have ALSA, I have the drivers, and everything is ready for me, but it needs to be initialised. By default, it’s not initialised because Debian (if you choose this option during installation) doesn’t run/initialise anything you didn’t explicitly request (and I love it).

The initialization is quite simple: sudo alsactl init. However, I cannot use it because this command is part of the alsa-utils package, which is not installed by default on my setup and is not included in the standard system utilities. Therefore, I need to install it first.

$ sudo apt install alsa-utils
$ sudo alsactl init
Found hardware: "HDA-Intel" "Realtek ALC897" "HDA:10ec0897,104387fb,00100402" "0x1043" "0x87fb"
Hardware is initialized using a generic method
Found hardware: "HDA-Intel" "Nvidia GPU 9f HDMI/DP" "HDA:10de009f,1043881d,00100100" "0x1043" "0x881d"
Hardware is initialized using a generic method

Aaaannd magic! Public Memory divine music is in my ears!

Is ALSA restrictive in some way? Does it work only for one audio stream at a time?

For development purposes, I have multiple browsers installed, so I opened another Public Memory song in a different browser and played it simultaneously. It works—I hear the overlaying audio of both songs.

I think it’s time to set up Bluetooth management tools and try listening to songs using my wireless headset.

Note: Regarding the question posed in the section title, I haven’t fully explored it yet. For now, it’s clear that ALSA is the key to audio input/output working on Debian, and it’s functioning well for little tests I performed. I’ll leave advanced tests—like using the microphone, testing apps for calls, etc.—for later, as my priority now is setting up Bluetooth to use my headset wirelessly.

➃ Bluetooth devices management tool

I have a Bluetooth adapter (dongle Edimax BT-8500) and a Bluetooth device (Marshall IV headset).
Basically, I just need to install the bluetooth metapackage.

Package: bluetooth (5.66-1+deb12u2)
This package provides all of the different plugins supported by the Bluez bluetooth stack

$ sudo apt install bluetooth

I won't be using any GUI for now; I'll use command-line tool bluetoothctl instead. First, I'll check if the bluetooth service is running.

$ systemctl status bluetooth
# if it is not running
$ sudo systemctl start bluetooth

Then, I run bluetoothctl and enter its CLI

$ bluetoothctl
[bluetooth]# power on
# i set the agent to handle pairing and set it to default mode:
[bluetooth]# agent on
[bluetooth]# default-agent
# start scanning devices
[bluetooth]# scan on
[NEW] Device XX:XX:XX:XX:XX:XX MAJOR IV
[bluetooth]# scan off
#numbers you see is unique MAC address of your audio device
# once I have the MAC address of my Marshall headset, I can initiate pairing:
# I PUT INTO PAIRING MODE MY MARSHALL HEADSET
[bluetooth]# pair XX:XX:XX:XX:XX:XX
Attempting to pair with 1C:6E:4C:84:CF:A7
[CHG] Device XX:XX:XX:XX:XX:XX Connected: yes
[CHG] Device XX:XX:XX:XX:XX:XX Bonded: yes
...
[CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: yes
[CHG] Device XX:XX:XX:XX:XX:XX Paired: yes
Pairing successful
[CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: no
[CHG] Device XX:XX:XX:XX:XX:XX Connected: no
[bluetooth]# scan off
##Hmm, pairing is successful, but connection is no...
[bluetooth]# connect XX:XX:XX:XX:XX:XX
Attempting to connect to XX:XX:XX:XX:XX:XX
Failed to connect: org.bluez.Error.Failed br-connection-profile-unavailable

The error isn’t very self-explanatory. Something seems off. Bluez's corresponding error description still not entirely clear:

Failed to find connectable services or the target service.

However, nothing to worry, this isn’t really about troubleshooting or debugging. I just wanted to gently point you back to the unanswered question in the previous section - is having only ALSA enough?

First off, there are two guides for Debian on Bluetooth usage: one for non-audio Bluetooth devices, and another specifically for Bluetooth audio devices. The second one, the right one for my case, explicitly states:

Pre-configuration
In short: To connect to a given device, you need Bluetooth hardware on your PC (either built-in, or in the form of a USB dongle), the Bluez daemon, and a compatible audio server (either PulseAudio or PipeWire). Alternatively Bluetooth ALSA available since Debian 12 bookworm allows to avoid running of a high-level sound server. (Debian Wiki: Bluetooth Audio)

So, there are two options here:

You stick with ALSA only, using an additional package Bluetooth ALSA. In this case, you don’t need PulseAudio or PipeWire for Bluetooth audio devices to work.
Both PulseAudio and PipeWire, as mentioned above, are audio servers.

However, it may still be unclear why I can't simply use ALSA if it worked for wired music playback, and what's missing from my system. The answer is that, without additional software, the Bluetooth codec used by my Marshall headset isn't supported.

A codec determines how Bluetooth transmits from the source device to your headphones. It encodes and decodes digital audio data into a specific format. In an ideal world, a high-fidelity signal would be possible at the minimum specified bit rate, resulting in the least amount of space and bandwidth required for storage and transmission. Lower bitrates actually mean better compression but often mean worse sound quality, a high bitrate usually means better sound quality and worse compression. (Source)

There are more advanced codecs and less advanced ones. However, the use of codecs is somewhat bilateral. I mean, the choice I mentioned above—that you can go for just an additional package like Bluetooth ALSA or choose one of the sound servers—can be partially guided by the support of audio codecs out of the box. In this case, the winner is PipeWire. However, if your audio input/output doesn't support advanced codecs, there's no way to utilize them.
Interestingly, despite using Bluetooth 5.0, the my Marshall Major IV supports only the default SBC audio codec. This codec is adequate and the connection is stable, however it’s not ideal (source).

So, actually for my setup just additional package for bluettohb audio devices support for ALSA is viable version:

The bluez-alsa-utilspackage supports the LDAC and SBC codecs. AAC support is not compiled into the official package, because the required library is only available in the non-free repository.
This will also automatically configure a "bluez-alsa" systemd service, and install the proper ALSA configuration files to glue everything together. No further steps should be necessary. If you run into issues after installation though, a reboot might help. (Source)

However, I would prefer to use a sound server on my setup.

➄ PipeWire vs Pulseaudio

Before comparing these two audio servers, it would be helpful to first understand what they do and why they’re needed except for the Bluetooth connection of audio devices.

In the previous article of this series, I installed and configured a display server as the first step in building my custom UI. The reason for this is that all graphical applications "live" on the display server, which handles all inputs and outputs. Moreover, there is an inter-process communication, the desktop bus, used by applications to communicate with each other, creating a kind of "graphical ecosystem".

A similar parallel can be drawn for sound servers. While ALSA is sufficient for many use cases, you might need a sound server for more advanced and dynamic audio usage. This includes not just playing music but also audio and video streaming, sharing screens with audio during calls, and leveraging advanced audio technologies and codecs. For most of these scenarios, a sound server becomes essential.

The difference between PulseAudio and PipeWire is somewhat analogous to the difference between the X11 display protocol and Wayland. The latter is a much newer technology, designed and developed to replace PulseAudio while addressing all of its shortcomings.

There’s nothing inherently wrong with PulseAudio—it’s neither abandoned nor outdated. However, PipeWire is more modern and, in some cases, offers out-of-the-box support for advanced audio devices without the need for tweaks or extra configuration. This isn’t relevant in my case since, as I mentioned, my Marshall Major IV headset only supports the very basic SBC Bluetooth codec. Nonetheless, I’ve decided to go with PipeWire.

PipeWire is a server and API for handling multimedia on Linux. Its most common use is for Wayland and Flatpak applications to implement screensharing, remote desktop, and other forms of audio and video routing between different pieces of software. Per the official FAQ, "you can think of it as a multimedia routing layer on top of the drivers that applications and libraries can use."
As opposed to PulseAudio's focus on consumer audio and JACK's focus on professional audio, PipeWire aims to work for all users at all levels. Among other techniques, PipeWire achieves this with its ability to dynamically switch between different buffer sizes, for adapting to the different latency requirements of different audio applications.
In Debian 12, PipeWire 0.3.65 is available, and is considerably more reliable, and is a comfortable drop-in replacement for many use-cases. PipeWire is the default sound server with GNOME Desktop. (Debian Wiki: PipeWire)

➅ PipeWire: Installation

In the previous article, while configuring the BSPWM window manager and display server, it was necessary to set up D-Bus for the X session. This is because, when initiating the graphical user interface with startx from the console, an X session managed by X11 is started, and it exists with BSPWM which executes all configurations specified in its setup.

Similarly, PipeWire requires a session manager to function effectively.

Two session managers are now available. The one pulled in by default (wireplumber) is the one recommended by pipewire's developers. The other one (pipewire-media-session) is primitive, and is best when using PipeWire just for its basic functionality like screensharing. When using PipeWire as your system's sound server, the maintainer recommends installing the more advanced WirePlumber instead. This command will install WirePlumber while removing the old session manager:_

So, I just need to install WirePlumber, and as a dependency, it will bring PipeWire to my system. There is this recommendation from Debian developers:

It is recommended to install the metapackage pipewire-audio which depends on wireplumber (the recommended session manager), pipewire-pulse (to replace PulseAudio), pipewire-alsa (ALSA) and libspa-0.2-bluetooth (for Bluetooth support). Moreover, installing this metapackage will remove pulseaudioto prevent any conflicts between both sound server. (Source)

*NB! The Debian 12 Bookworm stable repository has quite outdated versions of the PipeWire sound server (v. 0.3.65) and its dependencies. Since PipeWire is young and evolving quickly, it may be important to have a more up-to-date version installed. So, the option to install it from Bookworm backports may be viable (v. 1.2.5), and later on, I will show you how. *

However, even if you decide to go for it, make sure to read the text below and check the logs, because otherwise, you might not understand the XDG Desktop Portal. A version of WirePlumber and PipeWire from Bookworm backports doesn't seem to complain about it, but trust me, you'll most likely need the XDG Desktop Portal."

$ sudo apt install pipewire-audio
$ systemctl --user start wireplumber

Now, I’ll check if everything is okay with wireplumber service:

$ systemctl --user status  wireplumber
● wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-12-30 13:04:27 CET; 13s ago
....

Dec 30 13:04:27 wonderland systemd[1017]: Started wireplumber.service - Multimedia Service Session Manager.
Dec 30 13:04:27 wonderland wireplumber[6190]: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Dec 30 13:04:27 wonderland wireplumber[6190]: found session bus but no portal
Dec 30 13:04:27 wonderland wireplumber[6190]: Failed to set scheduler settings: Operation not permitted
Dec 30 13:04:27 wonderland wireplumber[6190]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Dec 30 13:04:27 wonderland wireplumber[6190]: PipeWire's libcamera SPA missing or broken. libcamera not supported.
Dec 30 13:04:28 wonderland wireplumber[6190]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5.

Wireplumber is running, but there are a couple of things that aren't okay. Let's go through them one by one with the errors.

wireplumber: Failed to set scheduler settings: Operation not permitted

This is definitely something about permissions. It might be related to the fact that PipeWire version available on Debian Bookworm is low, so the permission issue is most likely due to the absence of a specific user group (pipewire) created with the necessary permissions when PipeWire is installed. The default group is used, but PipeWire needs more. Personally, I would leave it as is and only debug if something really doesn't work.

PipeWire's libcamera SPA missing or broken. libcamera not supported.

This is just about a PipeWire plugin, and depending on whether you need it or not, you can install it. I don't need it, so I’ll leave PipeWire to complain about the missing plugin. Here is the package for this plugin.

Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5
Well, here I am completely okay with it since I don't have devices that use legacy codecs. A2DP is exactly what I need:

Advanced Audio Distribution Profile (A2DP)
A standard for how Bluetooth devices that can stream high-quality audio to remote devices. This is most commonly used for linking wireless headphones and speakers to your PC. (Source)

What’s left is quite interesting, and it’s something you should pay attention to:

Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
found session bus but no portal

pipewire service reports the same issue in slightly different manner:

$ systemctl --user  status pipewire
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-12-30 13:04:27 CET; 12min ago
TriggeredBy: ● pipewire.socket
....

Dec 30 13:04:27 wonderland systemd[1017]: Started pipewire.service - PipeWire Multimedia Service.
Dec 30 13:04:27 wonderland pipewire[6189]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Dec 30 13:04:27 wonderland pipewire[6189]: mod.rt: found session bus but no portal
alisa@wonderland:~$

So, DBus User Message Bus is running correctly (I dedicated a very detailed attention to configuring it in the previous article). But something related to the desktop is missing...

What even is this?

➆ About XDG Desktop Portal

XDG Desktop Portal
A portal frontend service for Flatpak and other desktop containment frameworks.
xdg-desktop-portal works by exposing a series of D-Bus interfaces known as portals under a well-known name (org.freedesktop.portal.Desktop) and object path (/org/freedesktop/portal/desktop). (Source)

Mostly, it’s needed for containerized software like Flatpaks, as the quote above says. However, it’s not only for this, and even if you don’t use Flatpak, you could still run into problems. A very trivial case could be with a browser like Mozilla or any other when you try to upload something, and the file chooser dialog is needed. It won’t work without the portal.

Portals were designed for use with applications sandboxed through Flatpak, but any application can use portals to provide uniform access to features independent of desktops and toolkits. This is commonly used, for example, to allow screen sharing on Wayland via PipeWire, or to use file open and save dialogs on Firefox that use the same toolkit as your current desktop environment. (Arch Wiki: XDG Desktop Portal)

XDG Desktop Portal can be installed with sudo apt install xdg-desktop-portal on Debian. HOWEVER, THE COMMON MISTAKE IS TO INSTALL ONLY THIS PACKAGE. XDG Desktop Portal needs at least one backend (can have also more). There are different backends available on Debian Bookworm:

xdg-desktop-portal-gnome
xdg-desktop-portal-gtk
xdg-desktop-portal-kde
xdg-desktop-portal-wlr

I will proceed with installation of xdg-desktop-portal first.

Package: xdg-desktop-portal
desktop integration portal for Flatpak and Snap
xdg-desktop-portal provides a portal frontend service for Flatpak, Snap, and possibly other desktop containment/sandboxing frameworks. This service is made available to the sandboxed application, and provides mediated D-Bus interfaces for file access, URI opening, printing and similar desktop integration features. (Source)

$ sudo apt install xdg-desktop-portal
$ systemctl --user start xdg-desktop-portal
$ systemctl --user status xdg-desktop-portal
● xdg-desktop-portal.service - Portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
     Active: active (running) since Mon 2024-12-30 13:29:28 CET; 1s ago
 ....

Dec 30 13:29:28 wonderland systemd[1017]: Starting xdg-desktop-portal.service - Portal service...
Dec 30 13:29:28 wonderland xdg-desktop-por[7132]: No skeleton to export
Dec 30 13:29:28 wonderland systemd[1017]: Started xdg-desktop-portal.service - Portal service.

$ systemctl --user  restart wireplumber

$ systemctl --user  status wireplumber
● wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-12-30 13:29:46 CET; 7s ago
   ...

Dec 30 13:29:46 wonderland systemd[1017]: Started wireplumber.service - Multimedia Service Session Manager.
Dec 30 13:29:46 wonderland wireplumber[7157]: Failed to set scheduler settings: Operation not permitted
Dec 30 13:29:46 wonderland wireplumber[7157]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Dec 30 13:29:46 wonderland wireplumber[7157]: PipeWire's libcamera SPA missing or broken. libcamera not supported.
Dec 30 13:29:47 wonderland wireplumber[7157]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5.

WirePlumber just wanted the XDG Desktop Portal available, without the specific backend. So, after installing the XDG Desktop Portal and starting it as a service, the errors in the WirePlumber and PipeWire services related to the XDG portal disappeared (after restarting both of them).

However, the XDG Desktop Portal service itself is reporting that no backend was found: xdg-desktop-portal[7132]: No skeleton to export.

I already mentioned that even if you don’t use Flatpaks, you can still encounter problems with other apps, like browsers. The backend is easy to choose when you have the default DE: if it’s GNOME, then xdg-desktop-portal-gnome; if it’s KDE, then xdg-desktop-portal-kde. These are usually installed automatically if you have installed one of default DEs. I would install the GTK backend (xdg-desktop-portal-gtk). Why? For example, Firefox depends on GTK, and I also use GIMP, which depends on GTK. In general, GTK will be completely enough for me. But please note, some Flatpaks depend on other services that require a specific backend, like GNOME for XDG Desktop Portal. If a Flatpak doesn’t work with GTK, you’ll have to check the logs to figure out what it needs and install it if necessary, possibly another backend.

$ sudo apt install xdg-desktop-portal-gtk

NB! You need to understand this sequence in order to decide how and when to launch the aforementioned services (wireplumber and xdg-dektop-portal).

The wireplumber service manages the sound server pipewire sessions.
If you enable it with systemctl --user enable wireplumber, it will start automatically on boot.
However, you cannot enable xdg-desktop-portal service in the same way! Moreover, even if you can do it manually, keep in mind that it will result in an error without the DISPLAY environment variable, just like dunst in the previous article.

So, I do not enable wireplumber because it will need to be restarted after xdg-desktop-portal is launched. Instead, I modify the bspwmrc config, so it handles it for me.

I add these lines (systemctl --user start xdg-dektop-portal,
systemctl --user restart wireplumber and systemctl --user restart pipewire):

$ sudo vim.tiny /etc/xdg/bspwm/bspwmrc
#! /bin/sh

#SXHKD Launching
pgrep -x sxhkd > /dev/null || sxhkd -c "/etc/xdg/bspwm/sxhkdrc" &

#DISPLAY env import
systemctl --user import-environment DISPLAY

#Starting XDG Desktop portal
systemctl --user start xdg-dektop-portal

#ReStarting Wireplumber
systemctl --user restart wireplumber
systemctl --user restart pipewire

#DUNST Launching
systemctl --user start dunst

#POLYBAR Launching
polybar-msg cmd quit

echo "---" | tee -a /tmp/polybar.log
polybar 2>&1 | tee -a /tmp/polybar.log & disown


bspc monitor -d I II III IV V

bspc config border_width         2
bspc config window_gap          12

bspc config split_ratio          0.52
bspc config borderless_monocle   true
bspc config gapless_monocle      true

You can do sudo reboot and then startx to check the success of modifications with:

systemctl --user status wireplumber systemctl --user status xdg-desktop-portal and systemctl --user status pipewire. Here is what I have:

Everything seems alrighty!
Time to test Bluetooth!

$ bluetoothctl
[bluetooth]# scan on
[NEW] Device XX:XX:XX:XX:XX:XX MAJOR IV
[bluetooth]# pair XX:XX:XX:XX:XX:XX
Attempting to pair with XX:XX:XX:XX:XX:XX
[CHG] Device XX:XX:XX:XX:XX:XX Connected: yes
[CHG] Device XX:XX:XX:XX:XX:XX Bonded: yes
Pairing successful
[bluetooth]# connect XX:XX:XX:XX:XX:XX
Attempting to connect to XX:XX:XX:XX:XX:XX
Connection successful
[MAJOR IV]# scan off

Connection successful! Start enjoying Public Memory - Zig Zag.

Now I can use the WirePlumber CLI to check if the device is registered there.

➇ Pipewire audio profiles: Understanding the difference between device profile headset-head-unit and a2dp

$ wpctl status
PipeWire 'pipewire-0' [0.3.65, alisa@wonderland, cookie:1612476836]
 └─ Clients:
 ...

Audio
 ├─ Devices:
 │      39. GA106 High Definition Audio Controller [alsa]
 │      40. Built-in Audio                      [alsa]
 │      51. MAJOR IV                            [bluez5]
 │
 ├─ Sinks:
 │      41. Built-in Audio Digital Stereo (IEC958) [vol: 0.40]
 │  *   52. MAJOR IV                            [vol: 0.60]
 │
 ├─ Sink endpoints:
 │
 ├─ Sources:
 │      42. Built-in Audio Analog Stereo        [vol: 1.00]
 │
 ├─ Source endpoints:
 │
 └─ Streams:

...

Sinks are audio output devices, and sources are audio input devices. As you can see, wpctl status shows that my Marshall headset is registered as a sink (so, output) and not as a source, so I can't use the microphone of my headset.

wpctl is similar to pactl, which is the PulseAudio CLI. However, you can use it with PipeWire without installing the PulseAudio server—just the utilities. So, I’ll do that because pactl is easier to use for me. pactl list output will help me explain why my headset is attached only as an output device.pactl is part of the pulseaudio-utils package.

$ sudo apt install pulseaudio-utils 
$ pactl list
Card #52
    Name: bluez_card.XX_XX_XX_XX_XX_XX
    Driver: module-bluez5-device.c
    Owner Module: n/a
    Properties:
                ....
        api.bluez5.connection = "connected"
        api.bluez5.device = ""
        bluez5.auto-connect = "[ hfp_hf hsp_hs a2dp_sink ]"
                ...
        device.alias = "MAJOR IV"
        device.api = "bluez5"
        device.bus = "bluetooth"
        device.description = "MAJOR IV"
        device.form_factor = "headphone"
                ....
    Profiles:
        off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
        a2dp-sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 16, available: yes)
        headset-head-unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 1, available: yes)
        a2dp-sink-sbc: High Fidelity Playback (A2DP Sink, codec SBC) (sinks: 1, sources: 0, priority: 18, available: yes)
        a2dp-sink-sbc_xq: High Fidelity Playback (A2DP Sink, codec SBC-XQ) (sinks: 1, sources: 0, priority: 17, available: yes)
        headset-head-unit-cvsd: Headset Head Unit (HSP/HFP, codec CVSD) (sinks: 1, sources: 1, priority: 2, available: yes)
        headset-head-unit-msbc: Headset Head Unit (HSP/HFP, codec mSBC) (sinks: 1, sources: 1, priority: 3, available: yes)
    Active Profile: a2dp-sink-sbc

Input is quite long, but you just have to find the card of your audio device. What’s important in the output are the profiles. For my Marshall IV headset, the available profiles (which my Marshall supports, and as I mentioned above, it’s not the highest-end codec it supports in terms of quality) are a2dp-sink (only output), a2dp-sink-sbc (only output), a2dp-sink-sbc_xq (only output), headset-head-unit (both input and output) and headset-head-unit-xvsd (both input and output).

Active Profile: a2dp-sink-sbc

a2dp-sink-sbc: High Fidelity Playback (A2DP Sink, codec SBC) (sinks: 1, sources: 0, priority: 18, available: yes)

You can see that there are no sources for this profile, only sinks! So, THIS IS THE REASON WHY I can use my Marshall only as an output device.

However, I am not bound to only one codec, automatically selected. I can switch it.

$ pactl set-card-profile bluez_card.XX_XX_XX_XX_XX_XX headset-head-unit
#I can change it back
$ pactl set-card-profile bluez_card.XX_XX_XX_XX_XX_XX a2dp-sink-sbc

NB! When I use the profile headset-head-unit to use the microphone, the sound quality is quite horrid. I guess this is connected to the maturity of PipeWire and the overall performance of Bluetooth audio devices on Linux, which is evolving rapidly but still has room for improvement. You can tweak the configuration, and if I find a solution to improve the audio quality, I will definitely share it. Most likely, it will be related to the configuration of PipeWire

(Optional)

Upgrading the PipeWire sound server version could be a partial remedy. For Debian Bookworm, the way to upgrade it is through the Bookworm backports:

#add bookworm-backports repo
$ sudo vim.tiny /etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free
$ sudo apt update
$ sudo apt install --reinstall -t bookworm backports pipewire-audio

That's all! See you in the next, conclusive part, which will be dedicated to having fun with Polybar, shell cuxtomization and installing some cool apps.

DEV Community: aL

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

1. Connecting to the router

1.1 Joining the router's network

1.2 Getting an IP address in router's LAN

Theory: How one PC/laptop joins multiple networks

Theory: Why /24 matters

1.3 Accessing LuCI from a web browser

2. Theory: Physical network devices vs. network interfaces

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

3. Layer 2 problem: one cable, multiple networks

Theory: IEEE 802.1Q and VLAN tags

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

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

4.1 ISP access control: MAC address filtering

4.2 Back to the configuration!

5. Configuring the wan network interface

5.1 Instruct wan interface to use custom DNS servers

Why should you care which DNS server you use

OpenWrt: Your Router, Your Rules - Part1: Keep or Bypass Your ISP's Router?

1. Connecting your OpenWrt router

1.1 LAN and WAN ports

1.2 Setup 1: Connecting router behind the ISP's router

1.3 Setup 2: Connecting router in place of the ISP's router

OpenWrt: Your Router, Your Rules - Part 0: Il diritto di scegliere il tuo router

1. Internet Service Provider e normativa europea

1.1 L'accesso a Internet è un mercato un po' particolare

1.2 Cambiare operatore in Italia

1.3 L'apparecchiatura fornita dal tuo operatore

1.4 Il modem TIM da 240 euro

1.5 Hai il diritto di usare il tuo router

2. Router con OpenWrt

2.1 Qualsiasi router può eseguire OpenWrt?

3. Come il tuo ISP ti collega a Internet

3.1 Internet senza fili (FWA)

3.2 Internet via cavo

3.3 FTTH: la fibra arriva dentro casa

4. ONT, modem e router

4.1 ONT e modem: sono la stessa cosa?

4.2 Il router

OpenWrt: Your Router, Your Rules - Part 0.5: NAT and CGNAT

1. IP address lease

1.1 DHCP

2. Network address translation

2.1 CGNAT

Why CGNAT is nasty?

OpenWrt: Your Router, Your Rules - Part 0: Your Router = Your Right.

1. Internet Service Providers and EU regulations.

1.1 Internet Service as a market's good

1.2 Italian regulations on switching ISP.

1.3 Home Internet equipment provided by you ISP.

1.4 TIM and their modem for 240 euros bundled with Internet Service offer.

1.5 EU law on freedom to choose your own equipment to use to access the Internet.

2. Router with OpenWrt

2.1 Any router can run OpenWrt?

3. How ISP connects you to the Internet.

4. Modem vs. ONT vs. Router

4.1 ONT vs. Modem

4.2 Router

Building Debian packages from source in bootstrapped Debian

Where to Start in Web Development: Ignoring Learning HTTP(S), URLs, DNS, IP, SSL Will Have Consequences...

1. Browser's Address Bar

2. URIs and URLs

3. HTTP Protocol

3.1 Internet Protocol and IP addresses

3.2 Transmission Control Protocol (TCP)

3.3 TCP/HTTP Network traffic

3.4 Understanding Ports

3.5 DNS

3.6 TCP in action: 3-way handshake

4. HTTPS

4.1 Little extra info: multiple IP addresses horizontal scaling of web apps

4.2 About encryption

4.3 TLS/SSL certificates

4.4 Secure communication channel

Where to Start in Web Development: Your Browser as Your First IDE

1. Building confidence with a browser

1.1 Open random files in your browser to see what happens

1.2 Browser's Developer Tools as an IDE (Integrated Development Environment)

2. How does a browser work?

5. Configuring the `wan` network interface

5.1 Instruct `wan` interface to use custom DNS servers

2.1 What is the `document`?

➀.➀ `virbrN` and `vnetN` - what do they do?

➁.➁ Modifying `/etc/network/interfaces`

➂.➂ Forwarding ports on the host with `firewalld`

➂.➃ Adding a rule to `nftables` ruleset to accept inbound network traffic to the VM

➁.➁ Network Interfaces: MAC addresses (`link/ether`)

➂.➁ Libvirt wants `iptables`, Debian has `nftables`: what to do?

➆.➂ VM creation with `virt-install`