Router

ASUS Router (RT-AC68U) Merlin Customizations & NixOS Router Feasibility

This guide covers step-by-step guidelines for doing advanced customizations (“funny things”) on your ASUS RT-AC68U router running Asuswrt-Merlin firmware, followed by an in-depth analysis of running NixOS or Nix-managed OpenWrt in a routing context.

Part 1: Step-by-Step Merlin Customizations

Your router is running Asuswrt-Merlin, which enables custom user scripts, cron jobs, and a package manager (opkg) via Entware.

Step 1: Access the Asuswrt-Merlin Terminal Menu (amtm)

Asuswrt-Merlin comes pre-installed with amtm (Asuswrt-Merlin Terminal Menu), a terminal-based interface to manage customizations.

1. SSH into your router:

   ssh asusrouter

2. Type amtm and press Enter:

   amtm

This menu is your launchpad for formatting drives, installing scripts, and managing system services.

Step 2: Prepare a USB Storage Drive (Required for Entware)

The internal flash memory of the RT-AC68U (mounted as /jffs) has very limited write cycles and space (~58MB free). Installing software directly onto the flash will wear out the NAND and brick the router.

1. Format a USB flash drive (USB 2.0 or 3.0) on your workstation as ext4 (or ext3).
2. Plug the USB drive into one of the USB ports on the back of the RT-AC68U.
3. Open amtm on the router.
4. Select fd (Format Disk) to verify the drive and partition it correctly for the router. Follow the on-screen prompts to enable swap memory (highly recommended for the RT-AC68U’s 256MB RAM).

Step 3: Install Entware & the opkg Package Manager

Entware is a software repository for embedded devices. Once the USB drive is configured:

1. In the amtm main menu, select ent (or run entware-setup.sh directly in the shell).
2. The script will automatically format the USB partition, mount it to /opt, and install the opkg package manager.
3. Exit amtm and verify opkg is available:

   opkg update

Step 4: Install Useful Terminal Utilities

Now you can install network diagnostics and utilities directly on the router:

• iperf3 (Measure local throughput between the router and client nodes):

  opkg install iperf3
  # Run iperf3 server on the router: iperf3 -s

• tcpdump (Diagnose connection states and packets on specific interfaces):

  opkg install tcpdump
  # Capture packets on WAN: tcpdump -i eth0

• htop & tmux (Monitor CPU cores and manage persistent shell sessions):

  opkg install htop tmux

Step 5: Install Advanced Scripting Add-ons (via amtm)

Using the amtm menu, you can install community-maintained scripts:

• Skynet: A border firewall script. It blocks known malware, phishing, trackers, and dynamic scanner IPs using iptables IP sets, protecting all local nodes.
• Diversion: A local ad-blocker. It intercepts DNS queries inside dnsmasq and returns 0.0.0.0 for ad servers (identical to Pi-hole but runs natively on the router’s hardware).
• vnStat: Tracks hourly, daily, and monthly network traffic stats.

Step 6: Hook into Custom Boot Scripts

Asuswrt-Merlin executes shell scripts located in /jffs/scripts/ at specific boot and configuration phases:

• /jffs/scripts/init-start: Executed early in the boot process (useful for custom kernel parameters).
• /jffs/scripts/nat-start: Executed when the WAN interface connects and NAT rules are applied (useful for custom firewall/routing configurations).
• /jffs/scripts/services-start: Executed after all system services have started (useful for launching custom daemons).

To create a script:

echo "#!/bin/sh" > /jffs/scripts/services-start
echo "logger 'My custom script executed successfully'" >> /jffs/scripts/services-start
chmod +x /jffs/scripts/services-start

Part 2: NixOS / Nix on Routers (In-Depth Analysis)

1. Can we deploy NixOS on the ASUS RT-AC68U?

Short Answer: No.

Deploying a standard NixOS configuration directly onto the ASUS RT-AC68U is practically impossible due to severe hardware and kernel constraints:

1. CPU & RAM Bottleneck: The RT-AC68U runs a Broadcom BCM4708 dual-core ARMv7l (32-bit ARM) processor with only 256MB of RAM. NixOS evaluations and package builds (nix-store / nixos-rebuild) require at least 1GB–2GB of RAM and will trigger Out-of-Memory (OOM) failures instantly.
2. Flash Capacity: The router has 128MB of NAND flash. A minimal NixOS system closure takes at least 500MB–1GB of storage.
3. Proprietary Broadcom Drivers: Broadcom’s Wi-Fi chips (BCM4360) and internal hardware switches rely on proprietary Broadcom kernel modules (wl.ko / et.ko). Mainline Linux does not support these components with full hardware acceleration, leaving the router without functional Wi-Fi or hardware switching under a generic NixOS kernel.
4. Architecture Deprecation: Nixpkgs has demoted armv7l-linux support, meaning binaries are no longer built or cached on the public binary cache, forcing compilation from source under QEMU emulation.

2. The Recommended Solution: NixOS on Modern Router Hardware

If you want a fully declarative, NixOS-driven router, the standard practice in the homelab community is to use dedicated x86_64 mini-PCs or modern ARM64 single-board computers (SBCs):

• Hardware Options:
  • x86_64 Mini-PC (e.g. Topton, Protectli, Qotom) with 4x Intel i226-V 2.5G ports.
  • ARM64 SBC (e.g. NanoPi R5S / R6S, or the Orange Pi 5 Plus which features dual 2.5GbE ports; see the sbc-opi5p.md host configuration for details on deploying it as a primary router or bypass gateway).
• NixOS Routing Declarations: NixOS excels as a router because networking, firewall rules, DHCP, and DNS are declared cleanly:

{ config, pkgs, ... }: {
  # Enable IP forwarding
  boot.kernel.sysctl = {
    "net.ipv4.ip_forward" = 1;
    "net.ipv6.conf.all.forwarding" = 1;
  };

  # Declarative Firewall (nftables)
  networking.nftables = {
    enable = true;
    ruleset = ''
      table inet filter {
        chain input {
          type filter hook input priority filter; policy drop;
          ct state established,related accept
          iifname "lo" accept
          iifname "lan0" accept # Allow LAN access
        }
        chain forward {
          type filter hook forward priority filter; policy drop;
          iifname "lan0" oifname "wan0" accept # Forward LAN to WAN
          ct state established,related accept
        }
      }
      table ip nat {
        chain postrouting {
          type nat hook postrouting priority srcnat; policy accept;
          oifname "wan0" masquerade # NAT masquerade on WAN
        }
      }
    '';
  };

  # Local DHCP Server
  services.dhcpd4 = {
    enable = true;
    interfaces = [ "lan0" ];
    extraConfig = ''
      subnet 192.168.31.0 netmask 255.255.255.0 {
        range 192.168.31.100 192.168.31.200;
        option routers 192.168.31.1;
        option domain-name-servers 1.1.1.1, 8.8.8.8;
      }
    '';
  };
}

3. The Hybrid Solution: Managing OpenWrt routers via Nix

While you cannot run NixOS on the RT-AC68U, you can use Nix on your workstation to declaratively manage OpenWrt routers.

OpenWrt stores its configuration in text files under /etc/config/ using the UCI (Unified Configuration Interface) format. You can write a Nix library function that translates Nix attribute sets into UCI config files, compiles them, and deploys them to the router over SSH.

Example: Declarative Nix Configuration for OpenWrt DHCP

You can define your router leases in your system configuration Nix files, and use a build script to generate the /etc/config/dhcp config file:

# A Nix function that generates OpenWrt UCI configuration syntax
let
  generateUci = type: name: attrs:
    "config ${type} '${name}'\n" +
    (lib.concatStringsSep "\n" (lib.mapAttrsToList (k: v: "    option ${k} '${toString v}'") attrs)) +
    "\n\n";
in
{
  # Define static leases in Nix
  environment.etc."openwrt-dhcp".text = 
    (generateUci "dnsmasq" "dnsmasq" {
      domainneeded = 1;
      localise_queries = 1;
      readethers = 1;
    }) +
    (generateUci "host" "id3-eniac" {
      name = "id3-eniac";
      mac = "10:7b:44:8e:fe:b4";
      ip = "192.168.31.11";
    }) +
    (generateUci "host" "nas-nasa" {
      name = "nas-nasa";
      mac = "24:5e:be:58:63:c9";
      ip = "192.168.31.12";
    });
}

Deployment:

Add a shell script to your bin/ directory that syncs the generated configurations:

#!/usr/bin/env bash
# Compile the Nix OpenWrt configurations and push to the router
nix-build -A config.environment.etc.openwrt-dhcp
scp result/etc/openwrt-dhcp asusrouter:/etc/config/dhcp
ssh asusrouter "/etc/init.d/dnsmasq restart"

This hybrid workflow gives you declarative git-tracked configurations for your network topology without needing to run heavy NixOS software closures on embedded router hardware.

Part 3: Soft Router (Software-Defined Routing) Platforms

A Soft Router (软路由) is a software-defined router built on standard commodity x86_64 hardware (like Intel/AMD mini-PCs with multi-port i226-V 2.5G network interfaces) or ARM64 boards (NanoPi, Raspberry Pi). By decoupling the routing software from proprietary hardware, you gain access to enterprise-grade firewall protection, high-performance VPN encryption throughput, and flexible service hosting.

1. Mainstream Soft Router Systems Compared

2. In-Depth System Comparison

A. OpenWrt (The Package Powerhouse)

• Core Functions: Routing, NAT, DHCP, DNS, wireless AP control, and traffic shaping.
• Pros:
  • Massive package ecosystem (via opkg). Easily runs tools like Sing-box, Clash, AdGuard Home, Docker, and Samba.
  • Extremely lightweight. Can run on systems with as little as 128MB of RAM.
  • Native hardware NAT acceleration shortcuts (shortcut-fe / flow offloading) for gigabit routing on low-power CPUs.
• Cons: Firewall management via standard OpenWrt (fw4/nftables) can get messy when dealing with complex multi-VLAN enterprise rules.
• Use Case: Best if you need standard routing combined with advanced DNS redirection, smart VPN proxies, and lightweight local storage sharing.

B. OPNsense / pfSense (The Enterprise Firewall)

• Core Functions: Stateful packet filtering, intrusion detection (IDS/IPS), multi-WAN load balancing, and secure IPsec/WireGuard VPN server tunnels.
• Pros:
  • Professional L3/L4/L7 stateful firewall. Extremely secure and stable.
  • OPNsense supports Zenarmor (Sensei) for next-generation L7 application filtering (blocking traffic by category like social media, gambling, etc.).
  • Excellent interface and alias management, making VLAN routing and network segmentation highly intuitive.
• Cons: High hardware demands (requires at least 2GB–4GB of RAM and modern x86_64 CPUs). Bad support for Wi-Fi cards (FreeBSD has limited wireless driver support; access points must be external).
• Use Case: Best if your home network is segmented into multiple VLANs (IoT, guest, servers, work) and you prioritize border security and traffic isolation.

C. iStoreOS (The NAS-Router Hybrid)

• Core Functions: Simplified OpenWrt routing, Docker container orchestration, Samba/NFS filesharing, and media management.
• Pros:
  • Clean, simplified dashboard tailored for home users.
  • One-click installer app store for hosting Docker containers (Jellyfin, Nextcloud, Transmission) directly on the router device.
• Cons: Under the hood it is still OpenWrt, but with heavily modified configuration layers that can conflict if you try to make low-level CLI manual configurations.
• Use Case: Excellent for users running single-board hardware (like NanoPi R5S) who want their router to double as a lightweight NAS.

D. MikroTik RouterOS (The Telecom Standard)

• Core Functions: Professional routing protocols (OSPF, BGP, RIP), bandwidth shaping (HTB queues), MPLS, and advanced traffic tunneling.
• Pros:
  • Industrial stability. The routing engine is highly optimized and consumes negligible CPU/RAM.
  • Configured via WinBox (a fast, native GUI interface) which provides real-time traffic statistics.
  • Cloud Hosted Router (CHR) license allows running the official MikroTik OS on standard x86_64 VMs (Proxmox/ESXi) with full feature parity.
• Cons: Extremely steep learning curve. The interface is organized around networking primitives (IP, routing, interfaces, firewall tables) rather than consumer-friendly Wizards.
• Use Case: Best if you have complex multi-WAN connections, need to run advanced routing protocols, or require strict, high-throughput QoS bandwidth limiting.

3. Software Behavior Routers (上网行为管理与流量控制)

A Software Behavior Router (行为管理软路由) focuses on identifying, controlling, and auditing the network activities of connected clients. Unlike traditional routers that only make routing decisions based on IP addresses, ports, and protocols (Layer 3/4), behavior routers perform Deep Packet Inspection (DPI) to analyze application-layer payloads (Layer 7). This allows them to identify and control specific applications (e.g., WeChat, TikTok, BitTorrent, Steam) even when they use dynamic ports or standard encrypted HTTPS connections.

Core Functions of Behavior Routers:

1. Deep Packet Inspection (DPI) & Application Identification: Identifying hundreds of network protocols, applications, and games in real time.
2. Application-Based Policy Routing (DPI 分流): Routing traffic dynamically based on the application. For example, routing latency-sensitive gaming traffic through a low-latency ISP line, while routing heavy video streaming/P2P downloads through a cheap, high-bandwidth ISP line.
3. Smart Traffic Control (智能流控 / QoS): Dynamically allocating bandwidth per user or per application to prevent a single download task from exhausting the WAN upload/download queues.
4. Behavior Filtering (应用过滤 & 网站阻断): Restricting access to specific categories of applications (e.g., blocking gaming, torrenting, or video streaming during work hours) and filtering malicious or unwanted URLs.
5. Network Auditing & Captive Portals (上网审计 & 认证网关): Requiring client authentication (SMS, WeChat, or Portal accounts) and logging DNS queries, URL access history, and bandwidth usage for security or compliance.

4. Mainstream Behavior Routing Solutions

A. iKuai (爱快) — The Commercial Home/SMB Favorite

• OS Base: Linux (Closed-source proprietary, but free for personal/basic usage).
• DPI Performance: Extremely high accuracy for Chinese internet environments. The DPI library is updated weekly to track changes in popular games, video sites, and apps.
• Key Features:
  • Policy Routing: Extremely intuitive rules to route specific apps to different WANs.
  • Built-in AC Controller: Seamlessly manages iKuai APs.
  • Captive Portal: SMS, WeChat, and Voucher authentication options.
  • Smart Flow Control: Outstanding default dynamic QoS algorithm that requires zero complex configuration.
• Hardware Requirements: Moderate (x86_64, minimum 2GB-4GB RAM).
• Pros: User-friendly Web GUI, highly optimized multi-WAN load balancing, excellent DPI detection rate.
• Cons: Closed-source, privacy-conscious users may worry about telemetry, does not support third-party Linux plugins (runs in a closed ecosystem).

B. Panabit (派网) — The Enterprise DPI Standard

• OS Base: FreeBSD (Closed-source core, free version limited to 256 concurrent IP clients).
• DPI Performance: The gold standard in China. Panabit developed some of the most sophisticated DPI engine technology, widely used by ISPs, universities, and large enterprises.
• Key Features:
  • Professional Traffic Shaping: Granular control over bandwidth allocation, down to specific packet queue priorities.
  • Virtual Line Multiplexing: Grouping physical links to act as a single high-performance pipe.
  • Detailed Network Audits: In-depth logging of protocol usage and access trends.
• Hardware Requirements: High (demands quality network cards like Intel NICs, x86_64, 4GB+ RAM).
• Pros: Incredible precision in flow control and application throttling; virtualizes well in Proxmox.
• Cons: Steep learning curve; the Web interface is industrial and complex; free tier has client IP limit.

C. OPNsense + Zenarmor (Sensei) — The Open-Source Next-Gen Firewall (NGFW)

• OS Base: FreeBSD / HardenedBSD (Fully open-source core; Zenarmor is a proprietary plugin with a generous free tier).
• DPI Performance: Enterprise-grade cloud-assisted DPI engine. Very accurate for global applications and websites, with automated category updates.
• Key Features:
  • L7 Application Control: Block or rate-limit web categories (social media, proxy bypass, adult content) and individual apps (e.g., Facebook, BitTorrent).
  • TLS/SSL Inspection: Ability to decrypt and analyze TLS traffic using local CA certificates.
  • Real-time Analytics: High-quality security graphs, threat alerts, and activity reporting.
• Hardware Requirements: High (Requires modern multi-core CPU and 4GB-8GB RAM).
• Pros: Highly secure, fully integrated into the OPNsense GUI, exceptional privacy controls.
• Cons: Subscription required for advanced features (like Active Directory integration or custom web categories); heavy RAM/CPU footprints.

D. OpenWrt + OpenAppFilter (OAF) — The Lightweight DIY Option

• OS Base: Linux (Fully open-source).
• DPI Performance: Basic kernel-level DPI module. Good for blocking standard games, video services, and downloads, but signatures must be updated manually.
• Key Features:
  • OpenAppFilter (OAF): A LuCI application and kernel module that matches packet headers against a signature database to identify apps.
  • Custom Signatures: Users can write custom patterns to identify and block local apps.
• Hardware Requirements: Extremely low (runs fine on 512MB RAM and ARM64 single-board routers like NanoPi).
• Pros: Entirely open-source, runs natively on standard OpenWrt without replacing the OS, light on resources.
• Cons: Signature updates are sporadic and community-driven; performance can degrade on cheap CPUs if inspecting heavy traffic.

5. Behavior Routing Comparison Summary

6. Implementation Recommendation

• For Home Labs & SMBs in China: Use iKuai. It requires minimal tuning to achieve perfect smart flow control. If you need open-source plugins (like Sing-box/Clash), the common practice is to run iKuai as the primary gateway (for WAN connection, DHCP, DPI routing, and flow control) and set up an OpenWrt instance as a bypass gateway (旁路路由) to handle DNS proxies.
• For High-End Security & Privacy: Run OPNsense with Zenarmor. This provides a true next-generation firewall setup (comparable to Palo Alto or Fortinet) with full visibility over local web activities.
• For Low-Power ARM Hardware: Run OpenWrt with OpenAppFilter to easily restrict access to specific apps (like blocking children’s gaming devices) without hardware upgrades.

Part 4: Orange Pi 5 Plus (sbc-opi5p) as a Soft Router or Gateway

The Orange Pi 5 Plus features the Rockchip RK3588 (4x A76 + 4x A55) SoC and dual 2.5 Gbps Realtek RTL8125B Ethernet ports, making it an exceptional candidate for a low-power, high-performance soft router or bypass gateway.

There are two primary ways to deploy it:

1. Setup A: Transparent Bypass Gateway (旁路网关 / 旁路路由) — Recommended

In this configuration, the main router (ASUS or Xiaomi Router) remains the primary DHCP server and gateway for the LAN. The sbc-opi5p acts as a dedicated helper node. Only nodes that require advanced proxying (e.g., the QNAP NAS nas-nasa or workstations) route their traffic through it.

Internet ◄─── WAN ─── [ Main Router ] (192.168.31.1)
                            │
              ┌─────────────┴─────────────┐
              ▼                           ▼
      [ Workstation ]              [ sbc-opi5p ] (192.168.31.5)
      (Gateway set to               (Runs sing-box in TUN mode,
       192.168.31.5)                forwarding enabled)

NixOS Configuration for Bypass Gateway:

To configure sbc-opi5p to accept and forward traffic, update hosts/sbc-opi5p/modules/modules.nix:

1. Enable IP Forwarding:

   boot.kernel.sysctl = {
     "net.ipv4.ip_forward" = 1;
     "net.ipv6.conf.all.forwarding" = 1;
   };

2. Configure NAT Masquerading (nftables): Add nftables rules so that forwarded packets returning to the main gateway appear to originate from the sbc-opi5p MAC address, preventing asymmetrical routing issues:

   networking.nftables = {
     enable = true;
     ruleset = ''
       table ip nat {
         chain postrouting {
           type nat hook postrouting priority srcnat; policy accept;
           oifname "eth0" masquerade # Or "eth1" depending on your active LAN interface
         }
       }
     '';
   };

3. Routing Clients: On client machines (like QNAP NAS nas-nasa or other workstations):

   • Set Default Gateway to 192.168.31.5 (the IP of sbc-opi5p).
   • Set DNS Server to 192.168.31.5 (or let sing-box intercept DNS).

2. Setup B: Full Primary Gateway Router (主路由)

In this mode, the sbc-opi5p sits directly in between your WAN connection and local network. It handles firewall rules, NAT, DHCP leases, and DNS resolution.

Modem ◄─── WAN ─── [ eth0 (sbc-opi5p) eth1 ] ─── LAN Switch ─── Clients

NixOS Configuration for Primary Router:

1. Configure Interface Roles:

   networking = {
     useDHCP = false;
     interfaces = {
       eth0.useDHCP = true; # WAN port connected to modem
       eth1.ipv4.addresses = [{
         address = "192.168.31.1";
         prefixLength = 24;
       }];
     };
   };

2. Enable Firewall & NAT Rules: Configure nftables to block unsolicited incoming packets on eth0 while masquerading LAN outbound traffic:

   networking.nftables = {
     enable = true;
     ruleset = ''
       table inet filter {
         chain input {
           type filter hook input priority filter; policy drop;
           ct state established,related accept
           iifname "lo" accept
           iifname "eth1" accept # Accept LAN connections
         }
         chain forward {
           type filter hook forward priority filter; policy drop;
           iifname "eth1" oifname "eth0" accept # Forward LAN -> WAN
           ct state established,related accept
         }
       }
       table ip nat {
         chain postrouting {
           type nat hook postrouting priority srcnat; policy accept;
           oifname "eth0" masquerade # NAT masquerade on WAN
         }
       }
     '';
   };

3. DHCP Server Configuration: Enable a local DHCP server to dynamically lease IP addresses to the LAN:

   services.dhcpd4 = {
     enable = true;
     interfaces = [ "eth1" ];
     extraConfig = ''
       subnet 192.168.31.0 netmask 255.255.255.0 {
         range 192.168.31.100 192.168.31.250;
         option routers 192.168.31.1;
         option domain-name-servers 192.168.31.1, 1.1.1.1;
       }
     '';
   };

PPPoE Dial-up Configuration (For Bridged Modems)

If your fiber optic modem (ONT/光猫) is configured in Bridge Mode (recommended to avoid double-NAT), the sbc-opi5p needs to perform the PPPoE dial-up directly to obtain the WAN public IP.

1. Configure pppd client: Instead of DHCP on eth0, define your PPPoE credentials using the services.pppd client. This creates a virtual WAN interface named ppp0:

   networking = {
     useDHCP = false;
     interfaces.eth0.useDHCP = false; # Connected directly to ONT
     interfaces.eth1.ipv4.addresses = [{
       address = "192.168.31.1";
       prefixLength = 24;
     }];
   };
   
   services.pppd = {
     enable = true;
     peers.provider = ''
       plugin rp-pppoe.so
       eth0                  # Physical WAN port connected to ONT
       user "your_pppoe_username"
       password "your_pppoe_password"
       noipdefault
       defaultroute
       usepeerdns
       persist
       maxfail 0
       holdoff 5
     '';
   };

2. Update Firewall rules (nftables) for PPPoE (ppp0): Adjust the firewall and NAT rules to target the virtual interface ppp0 instead of eth0. You must also enable TCP MSS Clamping on ppp0 because PPPoE encapsulation lowers the effective MTU to 1492:

   networking.nftables = {
     enable = true;
     ruleset = ''
       table inet filter {
         chain input {
           type filter hook input priority filter; policy drop;
           ct state established,related accept
           iifname "lo" accept
           iifname "eth1" accept
         }
         chain forward {
           type filter hook forward priority filter; policy drop;
           iifname "eth1" oifname "ppp0" accept
           ct state established,related accept
           
           # TCP MSS Clamping to prevent packet fragmentation issues on PPPoE (1492 MTU)
           tcp flags syn tcp option maxseg size set rt mtu
         }
       }
       table ip nat {
         chain postrouting {
           type nat hook postrouting priority srcnat; policy accept;
           oifname "ppp0" masquerade # NAT masquerade on virtual PPPoE interface
         }
       }
     '';
   };

3. Downgrade existing Consumer Routers to Access Points: With sbc-opi5p acting as the primary gateway dialer and DHCP server:

   • Configure your existing Xiaomi Router (or ASUS router) to AP (Access Point) Mode or Wired Bridge Mode via its web UI.
   • Connect the Xiaomi router’s LAN port to your LAN switch (or directly to eth1 of the sbc-opi5p). It will now focus entirely on Wi-Fi wireless clients while the sbc-opi5p handles all routing, DNS, and proxying.

3. High-Performance Proxying with sing-box

The RK3588’s 4x Cortex-A76 cores easily handle heavy encryption tunnels (like VLESS+REALITY or WireGuard) at full line speeds.

To enable transparent proxying on the sbc-opi5p:

1. Turn on the sing-box module in hosts/sbc-opi5p/modules/modules.nix:

   modules.services.net.sing-box = {
     enable = true;
     tun.enable = true; # Directs local packet routing via TUN
     webPanel.enable = true;
   };

2. The proxy client will act as a transparent TPROXY/TUN gateway. Since it runs directly on the high-performance SBC, it can achieve 2.5 Gbps routing speeds without CPU thermal throttling or bottlenecking local file transfers.

Part 5: LAN Proxying & Gateway Bypassing (Proxying QNAP NAS via ros-rolling)

When running services like Container Station on the QNAP NAS (nas-nasa, 192.168.31.12), you may encounter connection timeouts when pulling Docker images (e.g., Client.Timeout exceeded while awaiting headers or net/http: request canceled while waiting for connection) due to network censorship or routing blocks.

To solve this, three potential solutions were analyzed:

1. Option 1: Router-Level Proxy (Merlin Customizations)

   • Mechanism: Running custom proxy software (like sing-box) directly on the primary ASUS RT-AC68U router.
   • Verdict: Rejected. The RT-AC68U features a weak dual-core 32-bit ARM CPU and 256MB of RAM. Heavy encryption proxy client processing causes high CPU usage, thermal throttling, and potential memory exhaustion. Additionally, consumer-grade Xiaomi routers do not support SSH access by default to run custom binaries.

2. Option 2: LAN Proxy Server (ros-rolling as Proxy)

   • Mechanism: Run sing-box on an always-on LAN workstation/server (like ros-rolling, 192.168.31.91 running Arch Linux), configure it to bind to all interfaces (0.0.0.0), and route the NAS traffic through it.
   • Verdict: Approved & Implemented. Highly stable and keeps routing logic simple without upgrading router hardware.
   • Configuration Steps:

     • On ros-rolling (192.168.31.91), update the sing-box config to include an inbound listener on 0.0.0.0:

       {
         "inbounds": [
           {
             "type": "mixed",
             "tag": "mixed-in",
             "listen": "0.0.0.0",
             "listen_port": 2080
           }
         ]
       }

     • On the QNAP NAS (nas-nasa), configure the system-wide proxy:

       1. Log in to the QTS Admin Web Panel.
       2. Go to Control Panel -> Network & File Services -> Network Access -> Proxy tab.
       3. Select Use a proxy server and set the Address/IP to 192.168.31.91 and Port to 2080.

     • CRITICAL: Docker Daemon Proxy Workaround (dockerd environment override): QTS system-wide proxy settings only affect standard system apps and do not propagate to the Container Station Docker daemon (dockerd). Because the Container Station scripts folder is world-writable (777 permissions), we directly patched the Docker wrapper script /share/CACHEDEV1_DATA/.qpkg/container-station/script/run-docker.sh on the NAS to force-inject the proxy variables right below the #!/bin/sh header:

       export http_proxy=http://192.168.31.91:2080
       export HTTP_PROXY=http://192.168.31.91:2080
       export https_proxy=http://192.168.31.91:2080
       export HTTPS_PROXY=http://192.168.31.91:2080
       export no_proxy=localhost,127.0.0.1,192.168.31.12,192.168.31.138
       export NO_PROXY=localhost,127.0.0.1,192.168.31.12,192.168.31.138

       This ensures that when dockerd is executed by supervisord, it inherits the correct proxy env for image pull actions.

     • How to restart the Docker Service: Restarting the service via SSH as the alienzj user will fail because re-binding the Unix socket /var/run/container-station/supervisor.sock requires root (admin) privileges. You MUST perform the restart via the QTS Web UI:

       1. Log in to the QTS Web Portal.
       2. Open the App Center.
       3. Search for Container Station, click the down arrow on the button, and choose Stop.
       4. Wait for the status to show stopped, then click Start to run the startup script cleanly as root.
       5. Verify that docker pull restic/rest-server:latest works.

3. Option 3: SBC Soft Router / Bypass Gateway (sbc-opi5p)

   • Mechanism: Deploy a dedicated high-performance single-board computer like the Orange Pi 5 Plus (sbc-opi5p, 192.168.31.5) as a transparent bypass gateway running sing-box in TUN mode (refer to Part 4 above).
   • Verdict: Highly Recommended for permanent setup. This offloads all encryption and proxy selection from client configurations and provides wire-speed transparent routing (2.5 Gbps) to the entire subnet or selected nodes.