Skip to content

WireGuard Dual Bucket Routing Optimization

Jump to bottom
BrodjagaRatnik edited this page Jun 12, 2026 · 2 revisions

Technical Guide: The 0.0.0.0/1 and 128.0.0.0/1 Routing Trick

When configuring WireGuard on Linux network managers (like ConnMan on LibreELEC), setting the traditional global default gateway (WireGuard.AllowedIPs = 0.0.0.0/0) can sometimes cause split-routing conflicts or routing loops. This happens because the physical interface (such as eth0 or wlan0) fights with the virtual VPN interface (wg0) over who controls the primary network path.

To bypass this without breaking ConnMan's internal daemon logic, we use a networking technique called Dual-Bucket Subnet Splitting:

WireGuard.AllowedIPs = 0.0.0.0/1, 128.0.0.0/1

1. The Mathematical Breakdown (CIDR Notation)

In standard IPv4 networking, a /1 netmask locks down only the very first bit of an IP address. By splitting the address space using a 0 bit and a 1 bit, we slice the entire global internet exactly in half:

  • 0.0.0.0/1
    • Bit Rule: Covers all IP addresses where the first bit is 0.
    • IP Range: Matches everything from 0.0.0.0 to 127.255.255.255.
  • 128.0.0.0/1
    • Bit Rule: Covers all IP addresses where the first bit is 1.
    • IP Range: Matches everything from 128.0.0.0 to 255.255.255.255.

Combined Result: Together, these two subsets cover 100% of all possible IPv4 addresses on earth, achieving the exact same total coverage as a standard 0.0.0.0/0 catch-all internet route.

2. Why This Fixes Routing Collisions (The Longest Prefix Match)

The Linux kernel routes network traffic based on a strict fundamental rule called the Longest Prefix Match (LPM). When multiple routes are available, the most specific subnet mask always wins.

  1. The Physical Interface (eth0): ConnMan assigns your main network wire a standard default gateway route. In Linux, a default gateway is represented as /0 (meaning 0 bits are pinned down; it is the broadest possible route).
  2. The VPN Interface (wg0): By defining 0.0.0.0/1 and 128.0.0.0/1, the kernel injects two explicit routes into the system table with a /1 netmask.

Because a /1 netmask is mathematically more specific than a /0 default gateway mask, the Linux kernel will always choose the /1 VPN path for public internet payloads.

This completely neutralizes ConnMan's ability to leak traffic or lock competing default routes on eth0, immediately eliminating connection dropouts, curl error status 28 timeouts, and speed test hangs.

3. Why Local Shares (Samba / SMB) and SSH Stay Unbroken

A common concern when routing internet traffic is losing access to local devices like a NAS, a Samba setup, or SSH remote controls. This trick leaves them entirely uncompromised because your local network route uses an even higher priority mask.

For example, if your home router subnet is 192.168.178.0, Linux automatically builds a local hardware route:

192.168.178.0/24 dev eth0

When you send a packet to your local Samba media server at 192.168.178.20, the kernel compares the available paths:

  • Route A: The general internet half (/1) via wg0
  • Route B: The local home network (/24) via eth0

Since a /24 netmask is far more specific than a /1 mask, Route B wins instantly. Local home file streaming and remote controls bypass the VPN tunnel and run at native gigabit hardware speeds over your local wire, while all outbound public web data is securely encrypted through the VPN interface.

Created by Doemela

Clone this wiki locally