Here is a truth that gets overlooked in the excitement of mesh radios and decentralized protocols: before you can build a network that spans a valley, a city, or a continent, you need to build a network that spans a room. The local area network (LAN) is the foundation upon which everything else in this book rests. Get it right, and your community network, your off-grid homestead, your disaster-resilient communication system all have a solid base. Get it wrong, and no amount of clever routing protocols or exotic radio hardware will save you.
A LAN is, at its simplest, a group of devices connected together in one location — a house, an office, a community center, a farm building — that can communicate with each other directly. Most people encounter LANs only in the context of their home router, a magic box provided by their ISP that they never think about until it stops working. But for our purposes, a LAN is something you build deliberately, configure precisely, and understand deeply.
What makes LANs especially interesting for alternative networking is this: a LAN does not require the internet. It never has. The internet is a network of networks — a way to connect LANs to each other across vast distances. But each individual LAN is a fully functional, self-contained communication system. You can share files, stream media, host websites, run chat servers, play games, and collaborate on documents — all without a single packet leaving your local network.
This chapter is about building LANs that work beautifully on their own, and that are designed from the ground up to become building blocks for the larger alternative networks we will construct in later chapters. We will cover the hardware, the software, the services, and the design patterns that make a local network genuinely useful.
Ethernet was invented in 1973 by Robert Metcalfe at Xerox PARC, and in the five decades since, it has outlived virtually every competitor. Token Ring? Dead. FDDI? Museum piece. ATM to the desktop? A footnote. Ethernet endured because it was simple, cheap, and — critically — it evolved. The Ethernet of today bears almost no resemblance to the original 2.94 Mbps coaxial bus network Metcalfe sketched on a napkin, but the name persists, and so does the core idea: a standardized way to move frames between devices on a local network.
Modern Ethernet runs over twisted-pair copper cables (the familiar RJ-45 connectors) and increasingly over fiber optic cables for longer runs and higher speeds. For the networks we are building, copper Ethernet is the workhorse.
Not all Ethernet cables are created equal. The cable you choose determines the maximum speed, the maximum distance, and the amount of interference your network can tolerate. Here are the categories that matter:
Cat5e (Category 5 enhanced) supports Gigabit Ethernet (1 Gbps) at distances up to 100 meters. It is the minimum you should use for any new installation. Cat5e cable is cheap, widely available, and perfectly adequate for most alternative network scenarios. If someone offers you a box of Cat5e for free, take it.
Cat6 supports Gigabit Ethernet at 100 meters and 10-Gigabit Ethernet (10 Gbps) at distances up to 55 meters. It has tighter specifications for crosstalk — the electrical interference between the twisted pairs inside the cable — which means it performs better in environments with lots of electromagnetic noise. For new installations where the price difference is small, Cat6 is a sensible default.
Cat6a (Category 6 augmented) supports 10-Gigabit Ethernet at the full 100-meter distance. It is thicker, stiffer, and more expensive than Cat6. For most alternative network deployments, Cat6a is overkill — but if you are wiring a building from scratch and want to future-proof for a decade or more, it is a reasonable investment.
Cat7 and Cat8 exist but are rarely relevant for our purposes. Cat7 uses non-standard connectors (GG45 or TERA), and Cat8 is designed for short-distance data center interconnects. Stick with Cat5e or Cat6 for alternative network deployments unless you have a specific reason to do otherwise.
One practical note that trips up beginners: cable category and connector quality both matter. A Cat6 cable with poorly crimped connectors will perform worse than a Cat5e cable with clean terminations. If you are making your own cables (and you should learn — it is a fundamental skill), invest in a decent crimping tool and practice until you can pass a cable tester consistently.
Ethernet’s 100-meter maximum distance applies to a single run between active devices. Beyond 100 meters, the signal degrades below reliable thresholds. If you need to go further, you have three options:
A network switch is a device that connects multiple Ethernet devices together and forwards frames between them based on MAC addresses. Unlike a hub — which blindly copies every frame to every port — a switch learns which device is connected to which port and sends frames only where they need to go. This is more efficient, more secure, and eliminates the collision problems that plagued shared-medium networks.
For alternative network building, switches are the most important piece of hardware you will buy. Here is what to look for:
Managed vs. unmanaged. An unmanaged switch is a plug-and-play device with no configuration options. You connect cables and it works. These are fine for simple networks. A managed switch provides a configuration interface — usually a web GUI and a command line — that lets you configure VLANs, port mirroring, link aggregation, quality of service, and other advanced features. For any network more complex than “a few devices in one room,” a managed switch is worth the extra cost.
Port count. Small switches have 5 or 8 ports. Larger ones have 16, 24, or 48 ports. Choose based on your current needs plus some headroom for growth. A 16-port switch is a good default for a community network node.
Speed. Gigabit switches (1 Gbps per port) are the standard and should be your minimum. Some newer switches offer 2.5 Gbps or 10 Gbps ports; these are nice but not necessary for most alternative network use cases.
Power over Ethernet (PoE). Some switches can deliver electrical power over the Ethernet cable to connected devices — access points, cameras, IP phones, and single-board computers. PoE switches cost more but can dramatically simplify deployments where running separate power cables would be impractical. We will discuss PoE in detail later.
Good budget options include the TP-Link TL-SG108E (8-port managed, under $30), the Netgear GS308T (8-port smart managed), and for larger deployments, used enterprise switches from Cisco, HP/Aruba, or Juniper that can be found for remarkably low prices on the secondhand market. A used Cisco Catalyst 2960 with 24 Gigabit ports and PoE can often be had for under $50.
A hub is a dumb repeater. It receives a frame on one port and copies it to every other port. Every device on a hub shares the same collision domain, which means only one device can transmit at a time, and if two devices transmit simultaneously, both frames are destroyed and must be retransmitted. Hubs are slow, wasteful, and insecure (any device can see all traffic).
Hubs are effectively extinct in modern networking. If you encounter one, replace it with a switch. The only reason to mention them is so you recognize one if you find it in a donation pile of networking equipment and know to set it aside.
Wi-Fi is the common name for the IEEE 802.11 family of wireless LAN standards. It provides the convenience of wireless connectivity — no cables to run, no holes to drill — at the cost of lower speeds, shared airspace, interference susceptibility, and security considerations. For alternative networks, Wi-Fi is indispensable: it connects the phones, laptops, and tablets that people actually use day-to-day.
The 802.11 standards have evolved significantly over the years. Here is what you need to know:
802.11b (1999): 2.4 GHz band, up to 11 Mbps. Ancient by modern standards, but devices supporting it still exist. Operates in the 2.4 GHz band, which is crowded but has good range and obstacle penetration.
802.11a (1999): 5 GHz band, up to 54 Mbps. Less interference than 2.4 GHz but shorter range. Released the same year as 802.11b but was more expensive and less popular.
802.11g (2003): 2.4 GHz band, up to 54 Mbps. Backward compatible with 802.11b. The first “fast enough for web browsing” wireless standard.
802.11n / Wi-Fi 4 (2009): Dual-band (2.4 GHz and 5 GHz), up to 600 Mbps with MIMO (multiple-input multiple-output) antennas. The first standard that made wireless genuinely competitive with wired Ethernet for most users. Still perfectly adequate for many applications.
802.11ac / Wi-Fi 5 (2014): 5 GHz only, up to 6.9 Gbps theoretical with 8 spatial streams (in practice, 200–800 Mbps is typical for consumer devices). Introduced MU-MIMO, allowing the access point to communicate with multiple devices simultaneously. This is the sweet spot for most current deployments.
802.11ax / Wi-Fi 6 (2020): Dual-band, up to 9.6 Gbps theoretical. The key innovations are OFDMA (Orthogonal Frequency-Division Multiple Access), which improves efficiency in dense environments by allowing multiple devices to share a single channel, and BSS Coloring, which reduces interference from neighboring networks. Wi-Fi 6 shines in environments with many simultaneous clients — exactly the kind of environment a community network creates.
Wi-Fi 6E extends Wi-Fi 6 into the 6 GHz band, providing additional spectrum and less congestion. Hardware is still relatively expensive but prices are falling.
Wi-Fi 7 (802.11be) is the latest generation, supporting 320 MHz channels and multi-link operation. Impressive on paper, but for alternative network purposes, Wi-Fi 5 or 6 equipment provides excellent performance at much lower cost.
For alternative networks, the practical advice is: buy Wi-Fi 5 (802.11ac) or Wi-Fi 6 (802.11ax) equipment. Both provide excellent performance. Wi-Fi 4 (802.11n) gear is acceptable as a budget option. Anything older should be retired.
The two primary Wi-Fi frequency bands offer a fundamental tradeoff:
2.4 GHz has better range and better obstacle penetration. Radio waves at lower frequencies diffract around objects more effectively and lose less energy passing through walls. A 2.4 GHz signal will carry further and work better through building materials than a 5 GHz signal. The downside: the 2.4 GHz band is only 70 MHz wide and shared with Bluetooth, microwave ovens, baby monitors, and every other Wi-Fi network in range. In dense environments, 2.4 GHz is often unusably congested.
5 GHz has more bandwidth (up to 500 MHz of spectrum), more non-overlapping channels, and less congestion. It supports the wider channel widths (80 MHz, 160 MHz) that enable the highest speeds. The downside: shorter range and poorer obstacle penetration. Walls, floors, and trees attenuate 5 GHz signals more than 2.4 GHz.
For alternative networks, the general strategy is: use 2.4 GHz for coverage (reaching distant devices, penetrating walls) and 5 GHz for capacity (high-speed connections where range is not an issue). Most modern access points support both bands simultaneously, and clients can be steered to the optimal band.
These terms are often used interchangeably, and the consumer networking industry does not help by selling devices that combine all three functions. Let us be precise:
An access point (AP) is a device that bridges wireless clients into a wired network. It has one or more radios (for Wi-Fi) and one or more Ethernet ports. It does not route traffic between networks or assign IP addresses — it simply bridges the wireless and wired sides so that wireless clients appear to be on the same network as wired devices.
A router is a device that forwards traffic between different networks. Your “home router” is actually a router, a switch, an access point, a DHCP server, a firewall, and often a modem — all in one box. This is convenient for consumers but terrible for understanding what each component actually does. In an alternative network, you often want these functions separated so you can place them where they are needed and configure them independently.
A bridge connects two network segments so they behave as one. A wireless bridge, specifically, uses a radio link to connect two physically separate Ethernet networks. You might use a wireless bridge to connect a building’s LAN to an access point on a neighboring rooftop, extending the network without running cable between the buildings.
Understanding these distinctions matters because in alternative network design, you will mix and match these components. You might have a Raspberry Pi acting as a router, a dedicated access point mounted on a wall, a managed switch connecting wired devices, and a wireless bridge linking to the building next door. Each component has one job, does it well, and can be upgraded or replaced independently.
Most people never consider building a network without an internet connection, because they think the internet is the network. But strip away the internet, and a LAN is still extraordinarily useful:
The key insight is that most communication is local. You share files with people in your house. You stream media to devices in your living room. You chat with colleagues in your office. The internet is needed only when the person or service you want to reach is somewhere else. An internet-less LAN handles the local use cases — which, for many people, are the majority of their use cases — without any external dependency.
When a device connects to a network, it needs an IP address. On a typical home network, the home router provides this service automatically via DHCP (Dynamic Host Configuration Protocol). On an internet-less LAN, you need to run DHCP yourself.
dnsmasq is the tool of choice for small to medium alternative networks. It is lightweight, easy to configure, and combines DHCP and DNS services in a single package. It runs beautifully on a Raspberry Pi or any Linux machine.
Install it on a Debian/Ubuntu system:
sudo apt update && sudo apt install dnsmasq
A minimal configuration for a local network:
# /etc/dnsmasq.conf
interface=eth0
dhcp-range=192.168.1.100,192.168.1.200,24h
dhcp-option=option:router,192.168.1.1
dhcp-option=option:dns-server,192.168.1.1
domain=local.lan
This tells dnsmasq to listen on eth0, assign IP addresses from 192.168.1.100 to 192.168.1.200 with 24-hour leases, announce itself as both the router and DNS server, and use local.lan as the local domain name.
For a network with no internet gateway, you might remove the router option entirely — there is no router because there is nowhere to route to. Or you can set the router to the address of the machine that will eventually serve as the gateway when you connect your LAN to a larger network.
isc-dhcp-server is the more traditional option, widely used in enterprise environments. It is more complex to configure but offers finer-grained control:
# /etc/dhcp/dhcpd.conf
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.200;
option domain-name "local.lan";
option domain-name-servers 192.168.1.1;
default-lease-time 86400;
max-lease-time 172800;
}
For most alternative network deployments, dnsmasq is the better choice. It is simpler, lighter, and its integrated DNS capabilities are a significant advantage.
IP addresses are for machines. Humans prefer names. On the internet, the Domain Name System (DNS) translates names like example.com into IP addresses. On a local network without internet, you need a local name resolution system.
mDNS (Multicast DNS) is the simplest solution. It allows devices to announce their own names on the local network using the .local domain, without any central DNS server. On Linux, the Avahi daemon implements mDNS. On macOS, it is built in (Apple calls it Bonjour). On Windows, it works if iTunes or Bonjour Print Services is installed, or with Windows 10 and later natively.
Install and enable Avahi on a Debian/Ubuntu system:
sudo apt install avahi-daemon
sudo systemctl enable --now avahi-daemon
Once Avahi is running, a machine with the hostname fileserver becomes reachable at fileserver.local from any mDNS-capable device on the same network. No configuration required.
For more control, you can supplement mDNS with dnsmasq’s DNS capabilities. Add local DNS records to your dnsmasq configuration:
# Additional entries in /etc/dnsmasq.conf
address=/wiki.local.lan/192.168.1.10
address=/chat.local.lan/192.168.1.11
address=/media.local.lan/192.168.1.12
Now devices on your network can reach your wiki at wiki.local.lan, your chat server at chat.local.lan, and your media server at media.local.lan — all resolved locally, no internet required.
Linux is the operating system of choice for alternative network infrastructure, and understanding its network configuration tools is essential. Modern Linux distributions use one of several network management systems:
systemd-networkd is the network manager built into systemd, used by default on many server distributions. Configuration files live in /etc/systemd/network/:
# /etc/systemd/network/20-wired.network
[Match]
Name=eth0
[Network]
Address=192.168.1.1/24
DHCPServer=yes
[DHCPServer]
PoolOffset=100
PoolSize=100
DNS=192.168.1.1
NetworkManager is the default on most desktop distributions. It can be configured via GUI, the nmcli command-line tool, or configuration files. For setting a static IP:
nmcli con mod "Wired connection 1" \
ipv4.method manual \
ipv4.addresses 192.168.1.1/24 \
ipv4.dns 192.168.1.1
nmcli con up "Wired connection 1"
netplan is used by Ubuntu as a frontend for either systemd-networkd or NetworkManager:
# /etc/netplan/01-lan.yaml
network:
version: 2
ethernets:
eth0:
addresses: [192.168.1.1/24]
nameservers:
addresses: [192.168.1.1]
Apply with sudo netplan apply.
For alternative network servers — Raspberry Pis, old laptops repurposed as network nodes, dedicated single-board computers — the pattern is usually the same: assign a static IP to the machine running network services (DHCP, DNS, file sharing), and let client devices obtain addresses dynamically via DHCP.
A quick Python script to verify your network configuration:
import socket
import subprocess
hostname = socket.gethostname()
local_ip = socket.gethostbyname(hostname)
print(f"Hostname: {hostname}")
print(f"Local IP: {local_ip}")
result = subprocess.run(["ip", "route"], capture_output=True, text=True)
print(f"Routes:\n{result.stdout}")
A LAN without services is just expensive wiring. The real value of a local network comes from the services you run on it — the applications that make the network useful for actual humans doing actual things. Here is a catalog of the most valuable services for an alternative network, all of which run happily without any internet connection.
File sharing is the most fundamental local network service, and you have several options depending on your needs:
Samba (SMB/CIFS) implements the Windows file sharing protocol on Linux. It is the best choice when your network includes Windows, macOS, and Linux clients, because all three operating systems have built-in support for SMB. A basic Samba share:
# /etc/samba/smb.conf (add to the end)
[shared]
path = /srv/shared
browseable = yes
read only = no
guest ok = yes
create mask = 0664
directory mask = 0775
Activate with sudo systemctl restart smbd. The share appears automatically on Windows and macOS file browsers, and can be mounted on Linux with mount -t cifs //server/shared /mnt/shared -o guest.
NFS (Network File System) is the traditional Unix/Linux file sharing protocol. It is faster than Samba for Linux-to-Linux transfers and integrates more cleanly with Unix permissions. Use it when your clients are all Linux:
# /etc/exports
/srv/shared 192.168.1.0/24(rw,sync,no_subtree_check)
Export with sudo exportfs -ra and mount on clients with mount server:/srv/shared /mnt/shared.
SFTP (SSH File Transfer Protocol) is not a dedicated file sharing service but rather file transfer over SSH. It is encrypted by default, requires no additional software (SSH is installed on every Linux system), and works well for occasional file transfers. For always-on shared directories, Samba or NFS is more convenient.
Storing media on a local server and streaming it to devices on your network eliminates dependence on streaming subscriptions and internet bandwidth:
Jellyfin is an open-source media server that organizes your movies, TV shows, music, and photos and streams them to any device with a web browser or the Jellyfin app. It automatically downloads metadata, generates thumbnails, and transcodes media for devices that cannot play the original format. Unlike Plex, Jellyfin is fully open-source, requires no account creation, and works perfectly without internet. Install it on a Debian-based system:
curl -fsSL https://repo.jellyfin.org/install-debuntu.sh | sudo bash
Access the web interface at http://server:8096 and point it at your media directories.
Kodi is a media center application designed to run on the device connected to your TV or display. While Jellyfin is a server that streams to clients, Kodi is a client that accesses media directly from network shares (via SMB or NFS) or from streaming servers. The two work well together: Jellyfin as the central media server, Kodi as the living room player.
A Raspberry Pi 4 or 5 running LibreELEC (a minimal Linux distribution designed to run Kodi) makes an excellent, inexpensive media player. Pair it with a NAS (network-attached storage) or even just an old laptop with a large hard drive running Jellyfin, and you have a complete local media streaming system for under $100 in hardware.
Communication is perhaps the most critical service on an alternative network. You want people to be able to talk to each other, and you want the system to work even when the internet is down:
Matrix (via Synapse) is a federated messaging protocol that supports text, voice, video, file sharing, and end-to-end encryption. Synapse is the reference server implementation. When deployed on a local network, Synapse handles all messaging locally — messages never leave your network. If you later connect your LAN to other LANs (or to the internet), Matrix’s federation protocol allows your local server to communicate with other Matrix servers seamlessly. This makes Matrix an excellent choice for alternative networks: it works in isolation and scales to a global federation without changing the user experience.
Installing Synapse is more involved than most services, but well-documented. On a Debian system:
sudo apt install matrix-synapse-py3
Users connect with Element (web, desktop, or mobile client) pointed at your local server address.
Rocket.Chat is a Slack-like chat platform that runs as a self-hosted server. It is easier to deploy than Matrix and provides a familiar interface for users accustomed to Slack or Microsoft Teams. For a LAN-only deployment, it works well as a local communication hub.
Every community, project, or household benefits from a shared knowledge base. A locally-hosted wiki serves as your network’s collective memory:
Wiki.js is a modern, full-featured wiki built on Node.js. It has a clean interface, supports Markdown editing, full-text search, and multiple authentication backends. It runs on very modest hardware and is straightforward to deploy with Docker:
docker run -d --name wiki \
-p 3000:3000 \
-e "DB_TYPE=sqlite" \
ghcr.io/requarks/wiki:2
Access at http://server:3000.
DokuWiki is a lightweight wiki that stores pages as plain text files — no database required. This makes it incredibly easy to back up (just copy the directory) and resilient (no database to corrupt). It is written in PHP and runs on any system with a web server. For a community network’s documentation, DokuWiki’s simplicity is a virtue.
If your community includes developers — or anyone who wants version control for text files, configuration files, or documentation — a local Git server is invaluable:
Gitea is a lightweight, self-hosted Git service written in Go. It provides a web interface similar to GitHub, with issue tracking, pull requests, code review, and CI/CD integration. It runs on minimal hardware (a Raspberry Pi handles it easily) and can be deployed as a single binary:
wget -O gitea https://dl.gitea.com/gitea/1.22/gitea-1.22-linux-arm64
chmod +x gitea
./gitea web
Access at http://server:3000. For a community network, Gitea provides collaborative development capabilities without any dependence on GitHub, GitLab, or any other external service. When you eventually connect to the internet or to other community networks, Gitea instances can mirror repositories between them.
When someone connects to your local network for the first time — especially guests or new community members — they need to know what services are available and how to use them. A captive portal is a web page that is automatically displayed when a device connects to the network, before the user can access anything else.
You have likely encountered captive portals at hotels, airports, and coffee shops, where they are used to collect login credentials or accept terms of service. On an alternative network, you can use the same mechanism for a friendlier purpose: welcoming users and directing them to available services.
The simplest approach is a welcome page served by a local web server, combined with DNS redirection. Configure your local DNS (via dnsmasq) to redirect all unknown domain lookups to your welcome page:
# In /etc/dnsmasq.conf
address=/#/192.168.1.1
This tells dnsmasq to resolve any domain that is not explicitly defined to 192.168.1.1, where your welcome page is hosted. When a device connects and tries to reach any internet address (which it cannot, since there is no internet), it gets redirected to your welcome page.
Host the welcome page with any web server — nginx, Apache, or even Python’s built-in HTTP server for testing:
import http.server
import socketserver
PORT = 80
DIRECTORY = "/var/www/welcome"
handler = http.server.SimpleHTTPRequestHandler
handler.directory = DIRECTORY
with socketserver.TCPServer(("", PORT), handler) as httpd:
print(f"Welcome page at http://0.0.0.0:{PORT}")
httpd.serve_forever()
For a more proper captive portal that integrates with the operating system’s automatic portal detection (the mechanism that makes your phone pop up a login page when you connect to public Wi-Fi), use nodogsplash:
sudo apt install nodogsplash
Nodogsplash runs on the gateway device, intercepts HTTP requests from unauthenticated clients, and serves a splash page. Once the user clicks through (or simply views the page), their device is “authenticated” and given normal network access. The configuration is straightforward:
# /etc/nodogsplash/nodogsplash.conf
GatewayInterface eth0
GatewayAddress 192.168.1.1
MaxClients 100
AuthIdleTimeout 480
Create your splash page as an HTML file at /etc/nodogsplash/htdocs/splash.html, including links to all your local services. This gives new users a guided entry point into your network.
Other captive portal options include CoovaChilli (more enterprise-focused, supports RADIUS authentication), pfSense’s built-in captive portal (if you are using pfSense as your router), and OpenNDS (a fork of nodogsplash with additional features like dynamic content and sophisticated authentication). For a community network, nodogsplash or OpenNDS hits the sweet spot between simplicity and functionality.
A flat network — one where every device is on the same subnet and can communicate freely with every other device — is simple but has significant drawbacks:
Security. If an IoT device (a smart thermostat, a security camera, a cheap Wi-Fi plug) is compromised, the attacker gains access to the same network as your file server, your chat server, and your personal devices. IoT devices are notoriously insecure: default passwords, unpatched firmware, and sometimes outright backdoors. Segregating them limits the blast radius of a compromise.
Performance. Broadcast traffic (ARP requests, mDNS announcements, DHCP discoveries) reaches every device on the subnet. On a large flat network, broadcast traffic can become a significant overhead. Segmenting the network limits broadcasts to their relevant segment.
Organization. Different types of traffic have different requirements. Guest devices should not see internal servers. IoT sensors do not need access to the media library. Admin devices need access to everything. Segmentation lets you enforce these boundaries.
A VLAN (Virtual Local Area Network) is a logical subdivision of a physical network. Devices on the same VLAN can communicate as if they were on the same physical switch, even if they are physically connected to different switches. Devices on different VLANs are isolated from each other and can only communicate through a router — just as if they were on physically separate networks.
VLANs are implemented using 802.1Q, an IEEE standard that adds a 4-byte tag to Ethernet frames identifying which VLAN they belong to. Managed switches use these tags to forward frames only to ports that belong to the same VLAN.
A typical alternative network might use three or four VLANs:
| VLAN ID | Name | Subnet | Purpose |
|---|---|---|---|
| 10 | Admin | 192.168.10.0/24 | Network infrastructure, servers, admin PCs |
| 20 | Users | 192.168.20.0/24 | Personal devices, laptops, phones |
| 30 | IoT | 192.168.30.0/24 | Smart home devices, sensors, cameras |
| 40 | Guest | 192.168.40.0/24 | Guest devices, limited access |
On a managed switch, you configure VLANs through the switch’s web interface or CLI. On a Linux router (such as a Raspberry Pi), you create VLAN interfaces:
# Create VLAN interfaces on the router
sudo ip link add link eth0 name eth0.10 type vlan id 10
sudo ip addr add 192.168.10.1/24 dev eth0.10
sudo ip link set eth0.10 up
sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip addr add 192.168.20.1/24 dev eth0.20
sudo ip link set eth0.20 up
To make these persistent, add them to your network configuration (netplan, systemd-networkd, or /etc/network/interfaces).
The router sits between VLANs and controls which traffic can cross between them. Use iptables or nftables to define firewall rules:
# Allow Admin VLAN to access everything
iptables -A FORWARD -i eth0.10 -j ACCEPT
# Allow Users to access servers on Admin VLAN
iptables -A FORWARD -i eth0.20 -d 192.168.10.0/24 -j ACCEPT
iptables -A FORWARD -i eth0.20 -o eth0.30 -j DROP
# IoT can talk only to IoT
iptables -A FORWARD -i eth0.30 -o eth0.30 -j ACCEPT
iptables -A FORWARD -i eth0.30 -j DROP
# Guest can access nothing internal
iptables -A FORWARD -i eth0.40 -j DROP
These rules enforce a security policy: admins see everything, users access servers but not IoT devices, IoT devices are quarantined, and guests are completely isolated. In practice, you would refine these rules further — perhaps allowing IoT devices to reach a specific home automation server, or allowing guests to access the captive portal — but the structure is clear.
For Wi-Fi networks, you can map VLANs to separate SSIDs. A single access point can broadcast multiple SSIDs, each tagged to a different VLAN. Your network might have:
CommunityNet → VLAN 20 (Users)CommunityNet-IoT → VLAN 30 (IoT)CommunityNet-Guest → VLAN 40 (Guest)OpenWrt, the open-source router firmware used on many alternative network devices, makes this configuration straightforward through its web interface (LuCI) or command-line configuration files.
Power over Ethernet delivers electrical power alongside data over standard Ethernet cables. This is tremendously useful for alternative networks, because many network devices — access points, cameras, sensors, single-board computers — need power, and running separate power cables to each one is often impractical.
The PoE standards:
802.3af (PoE): up to 15.4 watts per port, with about 12.95 watts available to the powered device after cable losses. Sufficient for most access points, IP phones, and basic IP cameras. Introduced in 2003.
802.3at (PoE+): up to 30 watts per port, with about 25.5 watts available. Handles more power-hungry access points (especially those with multiple radios), pan-tilt-zoom cameras, and devices like Raspberry Pis with attached USB peripherals. Introduced in 2009.
802.3bt (PoE++): up to 60 watts (Type 3) or 100 watts (Type 4) per port. Designed for high-power devices like video displays, laptops, and LED lighting. Uses all four pairs in the cable. Introduced in 2018.
There are also passive PoE injectors that deliver power outside the standard specifications. These are cheaper but can damage devices that do not expect power on the cable. Always verify compatibility before using passive PoE.
PoE is a game-changer for alternative network deployments:
Rooftop access points. Mount a weatherproof access point on a pole or chimney. Run a single Ethernet cable from the switch inside the building to the AP on the roof. The cable carries both data and power — no need for a weatherproof electrical outlet on the roof.
Point-to-point wireless bridges. Devices like the Ubiquiti PowerBeam or MikroTik SXTsq are designed for outdoor mounting and are powered exclusively via PoE. Run a cable from your switch to the device on the roof, and you have a wireless bridge to a neighboring building.
Remote sensor stations. A Raspberry Pi with an environmental sensor package, enclosed in a weatherproof box, powered by PoE, and connected back to your LAN via a single Ethernet cable. No power adapter, no power outlet, just one cable.
Temporary deployments. Setting up a network for an event, a field operation, or a disaster response? PoE lets you deploy access points and cameras by running a single cable from a central switch. Faster to set up, faster to tear down, fewer points of failure.
PoE switches cost more than non-PoE switches, and the total power budget matters. A switch advertised as “8-port PoE” with a 65W power budget cannot deliver full PoE (15.4W) to all 8 ports simultaneously — it can power only about 4 devices at full draw. Read the specifications carefully.
Budget options:
For alternative network budgets, the sweet spot is often a non-PoE managed switch for general use combined with individual PoE injectors for the few devices that need power delivery. Upgrade to a PoE switch when the number of powered devices justifies it.
One of the most practical and immediately useful techniques in alternative networking is connecting two LANs wirelessly. The scenario is common: you have a network in one building and want to extend it to another building without running cable between them. Maybe it is a neighbor’s house across the street, a barn on the other side of a field, or a community center down the block.
The simplest approach is a wireless bridge — a pair of devices, one at each end, that create a transparent link between the two networks. Devices on either side see each other as if they were on the same LAN. From the perspective of your switches, it is as if someone ran a very long Ethernet cable through the air.
Dedicated point-to-point wireless bridge hardware is designed specifically for this purpose. The key characteristics:
Popular hardware options:
Ubiquiti airMAX (NanoStation, NanoBeam, PowerBeam): the de facto standard for community networks. NanoStation Loco5AC delivers up to 450 Mbps at ranges up to 10 km, with street prices around $50–80 per unit. A pair costs less than $200 and can link two buildings with very high throughput.
MikroTik (SXTsq, Disc Lite): excellent performance at lower price points. The MikroTik SXTsq 5 ac is a high-performance 802.11ac bridge for around $50. MikroTik devices run RouterOS, which is more powerful but has a steeper learning curve than Ubiquiti’s interface.
TP-Link CPE series: budget options that work well for shorter distances. The CPE510 provides up to 300 Mbps at ranges up to 15 km (under ideal conditions) for under $40.
The setup procedure for a point-to-point bridge is straightforward:
A Python snippet to quickly verify connectivity across a bridge:
import subprocess
import sys
target = sys.argv[1] if len(sys.argv) > 1 else "192.168.1.2"
result = subprocess.run(
["ping", "-c", "5", target],
capture_output=True, text=True
)
print(result.stdout)
When two LANs are too far apart for a direct wireless link — or when they are connected through the internet and you want the connection to be secure and transparent — a VPN (Virtual Private Network) creates an encrypted tunnel between them.
WireGuard is the modern VPN of choice: fast, simple, and secure. It is built into the Linux kernel since version 5.6, and its configuration is dramatically simpler than older VPN solutions like OpenVPN or IPsec.
A basic WireGuard site-to-site configuration connecting two LANs:
On Site A (192.168.1.0/24):
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/24
PrivateKey = <site-a-private-key>
ListenPort = 51820
[Peer]
PublicKey = <site-b-public-key>
AllowedIPs = 10.0.0.2/32, 192.168.2.0/24
Endpoint = site-b.example.com:51820
On Site B (192.168.2.0/24):
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.2/24
PrivateKey = <site-b-private-key>
ListenPort = 51820
[Peer]
PublicKey = <site-a-public-key>
AllowedIPs = 10.0.0.1/32, 192.168.1.0/24
Endpoint = site-a.example.com:51820
Activate on both sides with sudo wg-quick up wg0. Once connected, devices on the 192.168.1.0/24 network can reach devices on the 192.168.2.0/24 network as if they were directly connected — routed through the encrypted WireGuard tunnel.
For alternative networks, VPNs serve as a way to interconnect geographically separated community LANs. Imagine three community centers in different neighborhoods, each with its own local network. A WireGuard mesh connecting all three creates a single logical network spanning the community, with all traffic encrypted in transit. Users on any network can access services hosted on any other network.
Let us put everything together with a concrete, end-to-end example. You are setting up a network for a community room — a shared space where people gather, work, learn, and collaborate. The network should provide file sharing, media streaming, local chat, and a welcome page for newcomers. No internet connection is required, though one can be added later.
| Item | Purpose | Approximate Cost |
|---|---|---|
| Raspberry Pi 5 (8GB) | Server (DHCP, DNS, services) | $80 |
| 256GB microSD card | Storage for the server | $25 |
| TP-Link TL-SG108E (8-port) | Managed Gigabit switch | $30 |
| TP-Link EAP245 | Wi-Fi 5 access point (PoE) | $60 |
| TP-Link PoE injector | Power the AP over Ethernet | $15 |
| Cat6 patch cables (various) | Network cabling | $20 |
| 2TB USB hard drive | Media and file storage | $60 |
| Total | ~$290 |
This is a complete, functional community network for under $300. You can reduce costs further by using a Raspberry Pi 4, an unmanaged switch, and a cheaper access point. You can increase capacity by adding a larger NAS, a more powerful server, or additional access points.
Step 1: Set up the Raspberry Pi.
Install Raspberry Pi OS Lite (no desktop needed for a server). Set a static IP address:
sudo nmcli con mod "Wired connection 1" \
ipv4.method manual \
ipv4.addresses 192.168.1.1/24
sudo nmcli con up "Wired connection 1"
Step 2: Install and configure dnsmasq.
sudo apt install dnsmasq
Edit /etc/dnsmasq.conf:
interface=eth0
dhcp-range=192.168.1.100,192.168.1.200,24h
dhcp-option=option:dns-server,192.168.1.1
domain=community.lan
address=/welcome.community.lan/192.168.1.1
# Redirect all unknown domains to welcome page
address=/#/192.168.1.1
Restart: sudo systemctl restart dnsmasq
Step 3: Install Avahi for mDNS.
sudo apt install avahi-daemon
sudo systemctl enable --now avahi-daemon
Step 4: Set up file sharing with Samba.
sudo apt install samba
sudo mkdir -p /srv/shared
sudo chmod 777 /srv/shared
Add to /etc/samba/smb.conf:
[community]
path = /srv/shared
browseable = yes
read only = no
guest ok = yes
Restart: sudo systemctl restart smbd
Step 5: Install Jellyfin for media streaming.
curl -fsSL https://repo.jellyfin.org/install-debuntu.sh | sudo bash
Mount the USB hard drive and point Jellyfin at it through the web interface at http://192.168.1.1:8096.
Step 6: Set up a welcome page.
Create a simple HTML welcome page:
sudo mkdir -p /var/www/welcome
sudo apt install nginx
Create /var/www/welcome/index.html with links to all your services:
\\192.168.1.1\community or smb://192.168.1.1/communityhttp://192.168.1.1:8096Configure nginx to serve this directory on port 80.
Step 7: Connect the hardware.
Connect the Raspberry Pi and the access point to the switch. Connect the PoE injector between the switch and the access point if using PoE. Configure the access point’s SSID and security (WPA3 if supported, WPA2 otherwise) via its web interface.
Step 8: Test everything.
Connect a laptop or phone to the Wi-Fi. Verify it gets a DHCP address in the 192.168.1.100–200 range. Open a browser — you should be redirected to the welcome page. Access the file share. Open Jellyfin. Verify mDNS resolution with ping raspberrypi.local.
Once your network is running, you want to know what is happening on it. Here is a concise Python script that scans your local network and reports active devices:
import subprocess
import re
def scan_network(subnet="192.168.1.0/24"):
"""Scan local network using ARP and return active hosts."""
subprocess.run(
["ping", "-b", "-c", "1", "-w", "1", "192.168.1.255"],
capture_output=True
)
result = subprocess.run(["arp", "-a"], capture_output=True, text=True)
hosts = re.findall(
r"\((\d+\.\d+\.\d+\.\d+)\) at ([0-9a-f:]+)", result.stdout
)
print(f"{'IP Address':<18} {'MAC Address':<20}")
print("-" * 38)
for ip, mac in sorted(hosts):
print(f"{ip:<18} {mac:<20}")
print(f"\nTotal active hosts: {len(hosts)}")
if __name__ == "__main__":
scan_network()
Run this periodically (or via cron) to keep track of devices on your network. For more sophisticated monitoring, consider deploying Prometheus and Grafana on your server — overkill for a small network, but invaluable as your community network grows.
Before we close this chapter, here are the design principles that should guide every local network you build for alternative networking purposes:
Simplicity. Every additional component is a potential point of failure. Use the minimum hardware and software needed to meet your requirements. A Raspberry Pi running dnsmasq and Samba is vastly more reliable — and more repairable — than a stack of enterprise appliances.
Documentation. Write down your network configuration. IP addresses, VLAN assignments, Wi-Fi passwords, service URLs — all of it. Put it on your local wiki. When you are not available and someone else needs to troubleshoot, documentation is the difference between a fixable problem and a dead network.
Modularity. Design your network so components can be replaced independently. If your DHCP server dies, swapping in a new Raspberry Pi and loading the configuration should take minutes. If your access point fails, a replacement should work with no changes to the rest of the network.
Security from the start. Use WPA3 (or at minimum WPA2) on Wi-Fi. Use VLANs to segment untrusted devices. Use SSH keys instead of passwords. Use encrypted protocols (HTTPS, SFTP, WireGuard) wherever possible. Security is harder to add retroactively than to build in from the beginning.
Scalability. Design your IP addressing and VLAN scheme to accommodate growth. Use a /24 subnet (254 addresses) even if you only have 10 devices. Use VLAN IDs that leave room for future additions. The cost of planning for growth is zero; the cost of redesigning a running network is significant.
Resilience. Plan for failures. What happens if the server loses power? What happens if the switch dies? What happens if someone trips over the Ethernet cable? Redundancy is expensive, but awareness of single points of failure is free. At a minimum, ensure your critical configurations are backed up somewhere other than the devices they run on.
In this chapter, we built up from raw cables and radio waves to a complete, functional local network capable of serving a community without any internet connection. We covered:
The local area network is the atom from which larger networks are composed. Every mesh network, every community wireless ISP, every intercommunity link described in later chapters ultimately connects back to a LAN where people use devices and access services. Build your LANs well, and everything you build on top of them will be stronger for it.
In the next chapter, we move beyond the boundaries of a single location and explore mesh networking — the technology that allows multiple LANs and individual nodes to self-organize into resilient, decentralized networks that heal themselves when links fail.
| ← Previous: Networking Fundamentals and Topology | Table of Contents | Next: Mesh Networking → |