Building A Linux Router

Choosing the Right Parts and Cleaning Up the Machine

When the idea of turning a dusty old computer into a low‑cost, high‑performance router surfaced, the first thing that came to mind was the hardware. The pick was a second‑hand IBM Aptiva that had been rescued from a local bin. The specs were modest, but just enough for a lightweight Linux distribution to run from RAM:

• Pentium 150 MHz CPU
• 14 MB of RAM
• 1.6 GB hard drive
• 10 Mbps Ethernet controller
• CD‑ROM, sound card, monitor, keyboard, mouse, and a 2 MB integrated video card

Because the goal was to build a silent, energy‑efficient router, the first step was to strip the system of everything that was not strictly necessary. The internal hard disk and CD drive were removed, as they added no functional benefit for a headless machine and would only generate heat. The legacy sound card was also taken out. The 10 Mbps NIC was replaced with two 100 Mbps PCI cards (both from D‑Link) to increase bandwidth for the internal network and to provide a dedicated uplink to the Internet. The Aptiva only has two PCI slots, so that was the optimal use of the available hardware.

After physically removing the components, the machine was placed on a small desk in the basement and wired with a short patch cable to a switch that would feed the LAN. The router would sit in the corner, its monitor disconnected, and its power supply tucked out of sight. All this extra work meant the router would be quieter and cooler, making the setup more pleasant to use over the long haul.

Next came the question of the operating system. The original plan was to run a full distribution from a hard drive, but that would negate the benefits of a lean, flash‑based system. The answer was Coyote Linux – a single‑floppy distribution that boots straight into RAM. The project team reviewed the Coyote Linux documentation and confirmed that the distribution could support the hardware: the RTL8139 NIC driver is included in the kernel, and the kernel size is well below the 16 MB limit of a standard floppy. The distribution also ships with a simple setup wizard that allows you to choose the network type, enable DHCP, install an SSH server, and more. For a small office or home network, this level of flexibility is more than enough.

While preparing the hardware, I kept a running inventory of all the parts that would later be needed for troubleshooting. In case the router failed to boot or a driver was missing, having a spare 1 GB 3.5‑inch floppy drive and a set of blank disks on hand saved hours of downtime. This practical precaution proved valuable when the machine eventually started its first boot sequence.

After the hardware was stripped down, the next step was to prepare the boot disk. The process was straightforward but required a Linux environment on a laptop to run the provided scripts. That laptop ran Debian, which was comfortable for the author. The Coyote Linux Floppy Creator scripts were downloaded, unpacked, and executed. The script asked for a series of choices: the capacity of the disk (the smallest, medium, or largest), the processor type (Pentium or Pentium‑pro), the Internet connection method (Ethernet, PPPoE, dial‑up, or ISDN), whether to enable DHCP on the LAN, and whether to install SSH or a web‑based admin interface.

The default network configuration in Coyote Linux assigns 192.168.0.1 to the internal NIC, with a netmask of 255.255.255.0. That works for the majority of users, so I left those values unchanged. The script creates a file system on the floppy that contains the Linux kernel, a minimal root file system, and the chosen networking utilities. The resulting disk is a fully bootable router that can be inserted into the IBM Aptiva and run on its own without a hard drive.

With the boot disk ready, the machine was powered up and the BIOS was configured to boot from the floppy drive. The BIOS recognized the new 100 Mbps NICs as PCI devices, and the Linux kernel loaded the appropriate RTL8139 driver during startup. The console output confirmed that the kernel had reached the initialization stage and was loading the root file system from the floppy. At this point the system was ready to be connected to the Internet and configured for NAT.

Configuring NAT, Firewall Rules, and Remote Administration

Once the kernel booted, the first task was to ensure the router could forward traffic between the LAN and the Internet. The default setup in Coyote Linux already includes the netfilter/iptables stack, which manages packet filtering and NAT. The kernel command line contains the option “iptable_nat”, which tells the kernel to load the NAT module automatically. When the system boots, the iptables service starts and applies the default rule set that forwards packets from the internal interface to the external interface.

The next step was to enable the stateful firewall. The Coyote Linux distribution ships with a minimal iptables script that drops all unsolicited inbound traffic while allowing established connections to pass. This provides a basic level of protection without the complexity of a full‑featured firewall system. The default rules are:

• Accept traffic on the loopback interface (lo).
• Allow all outgoing traffic on the external interface (eth0).
• Drop all incoming traffic on eth0 that is not part of an established connection.
• Accept all traffic on the internal interface (eth1).

Those rules were adequate for the home network, but I added a few custom rules to block unwanted ports. For example, I added a rule to drop any traffic targeting port 23 (telnet) and port 21 (FTP) on the external interface, protecting the router from brute‑force attempts. The rule set was edited manually with the iptables command, then saved to the iptables configuration file so it would persist across reboots.

With NAT and firewall rules in place, the router needed a method for remote management. Coyote Linux offers an optional SSH server, and the creation script asked whether to install it. SSH provides a secure channel for administrators to log in and modify configuration files, restart services, or review system logs. In this setup, I enabled SSH by selecting “yes” during script execution. The sshd service starts automatically, and the router comes with a default user account “root” protected by a password. The password was set to a strong, unique value after the initial boot.

The router also offers a lightweight web administration interface called “Webadmin.” This tool can be accessed from any browser on the LAN by pointing to http://192.168.0.1/webadmin. The interface allows the administrator to view routing tables, change network settings, and view logs without accessing the command line. However, I chose not to install Webadmin to keep the image as small as possible. If a user prefers a graphical interface, installing the package is as simple as adding “webadmin” to the list of optional components in the Coyote Linux installer.

After setting up the firewall and SSH, I checked the routing table with the “netstat -rn” command. The output confirmed that the default route pointed to the ISP modem, and that the NAT rule was active. The next test was to confirm that the router could resolve DNS queries. Using “dig @192.168.0.1 google.com” verified that the DNS resolver on the router forwarded the query correctly and returned a valid IP address.

Finally, the router’s internal network was configured. On Windows, the clients were set to use DHCP, which was optional to enable in the Coyote Linux script. If DHCP was disabled, static IP addresses were assigned to each computer manually: 192.168.0.10 for the primary PC, 192.168.0.11 for the laptop, and so on. Each client’s default gateway was set to 192.168.0.1. After applying the settings, ping tests between clients and to an external domain (e.g., ping www.nokia.com) confirmed that traffic flowed correctly and the router’s NAT was functioning as intended.

With the core services running, the last step was to clean up the router’s front panel. The monitor and keyboard were disconnected, and a small enclosure was used to mount the power supply and the NIC cards. A single Ethernet cable ran from the ISP modem to the external NIC, and another cable ran from the router’s internal NIC to the network switch. The machine sat quietly, drawing less than 15 W of power, and the LAN users experienced fast, reliable Internet access without any trace of the router’s presence.

Extending the Router: Advanced Features and Maintenance Tips

While the basic configuration delivers a stable, NAT‑enabled router, there are several enhancements that can improve performance, security, and manageability. One of the first things to consider is enabling a full DHCP server on the LAN. Coyote Linux includes the dhcpd daemon, and the installer asks whether to activate it. Once enabled, the router automatically assigns IP addresses to clients, relieving the network administrator of manual configuration. The DHCP scope can be adjusted in /etc/dhcp/dhcpd.conf, allowing a larger address pool or setting lease times that match the network’s usage patterns.

Another useful feature is a captive portal for guests. By configuring iptables to redirect HTTP traffic from a designated “guest” subnet to a web page, visitors can be prompted to accept terms before gaining Internet access. This is straightforward to implement with a simple iptables rule and a static HTML file on the router’s file system. The portal can also enforce bandwidth limits, preventing a single user from saturating the uplink.

For users who need to monitor traffic in real time, the “iftop” utility offers a console‑based view of network usage per connection. Installing it from the APT repositories (apt-get install iftop) and launching it as root provides instant insight into which hosts are consuming the most bandwidth. This can be invaluable when troubleshooting slow network segments or detecting unusual traffic patterns.

Maintenance of the router is minimal due to its RAM‑based file system. All updates are performed by re‑creating the boot disk with the latest Coyote Linux image. If the router’s firmware needs to be upgraded, the same Floppy Creator script is run again, selecting the newer kernel version. Because the system doesn’t rely on persistent storage, no boot sector or configuration file corruption can occur, and the router can be restored to a known state simply by reinserting a fresh disk.

Security hygiene is critical, especially for a device that sits at the gateway of a network. A routine check of the firewall rules and the list of allowed SSH users helps prevent unauthorized access. Disabling root logins over SSH and using key‑based authentication can further harden the system. Moreover, keeping the router’s network interface names consistent (eth0 for WAN, eth1 for LAN) avoids confusion when applying rules or troubleshooting connectivity issues.

For those interested in more sophisticated routing protocols, installing the Quagga or FRRouting packages turns the router into a full‑featured Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF) router. These tools are optional and require additional configuration, but they open the door to advanced network designs such as redundant paths or load‑balanced connections. The trade‑off is a higher memory footprint, but with a 14 MB RAM machine the core functionalities remain stable.

In sum, the upgraded router can become a versatile hub for a small office or a smart home. The base Coyote Linux image provides reliable NAT and firewall protection. Optional modules such as DHCP, captive portal, traffic monitoring, and advanced routing protocols can be added as needed. The hardware remains simple, the power consumption is low, and the system’s stateless nature ensures that any misconfiguration can be reset by swapping the boot disk.