<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mwan3 on Marcello Barnaba</title>
    <link>https://sindro.me/tags/mwan3/</link>
    <description>Recent content in Mwan3 on Marcello Barnaba</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 07 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://sindro.me/tags/mwan3/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How banIP Nuked My WireGuard Throughput Since February</title>
      <link>https://sindro.me/posts/2026-04-07-banip-icmp-mwan3/</link>
      <pubDate>Tue, 07 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://sindro.me/posts/2026-04-07-banip-icmp-mwan3/</guid>
      <description>&lt;p&gt;&lt;strong&gt;TL;DR:&lt;/strong&gt; If you run OpenWrt with mwan3 (multi-WAN failover) and a &lt;strong&gt;split-tunnel&lt;/strong&gt; WireGuard VPN (i.e., you&amp;rsquo;re NOT routing all traffic through it), add &lt;code&gt;nohostroute=1&lt;/code&gt; to your WireGuard interface. Without it, netifd creates a static route for the WireGuard endpoint at interface-up time, pinned to whatever uplink happens to be active at that moment. By the first corollary of Murphy&amp;rsquo;s Law, anything that can go wrong will go wrong &lt;em&gt;at the worst possible moment&lt;/em&gt; — so your primary link will be down precisely when WireGuard starts, and the endpoint route gets permanently stuck on the backup. Your VPN will be stuck on the slow backup while your primary link sits there doing nothing. You won&amp;rsquo;t notice until you need to transfer something big.&lt;/p&gt;&#xA;&lt;p&gt;(If you &lt;em&gt;are&lt;/em&gt; routing all traffic through WireGuard, you &lt;strong&gt;need&lt;/strong&gt; the host route to prevent a routing loop — but on a multi-WAN setup, the same stale-route problem applies. You&amp;rsquo;ll need a different workaround, like a hotplug script that updates the endpoint route when mwan3 switches uplinks.)&lt;/p&gt;&#xA;&lt;p&gt;Today I discovered that my WireGuard tunnel to a remote server has been crawling at &lt;strong&gt;2 Mbps&lt;/strong&gt; since early February. The fix took two UCI commands. The root cause was the missing &lt;code&gt;nohostroute&lt;/code&gt; flag — plus a bonus: my own firewall was sabotaging my own health checks, making the fiber look unreliable enough that the system never self-corrected.&lt;/p&gt;&#xA;&lt;p&gt;Here&amp;rsquo;s the full forensic story, because I&amp;rsquo;m still furious and you deserve to learn from my suffering.&lt;/p&gt;&#xA;&lt;p&gt;But first, some context on how this investigation actually happened. I was working with an AI coding assistant (Claude Code) that has SSH access to my infrastructure. This is possible because I have a clean foundation: SSH key authentication everywhere, proper internal DNS (&lt;code&gt;m42&lt;/code&gt;, &lt;code&gt;golem&lt;/code&gt; resolve to the right VPN addresses), WireGuard mesh between all nodes, and the assistant connects through a &lt;code&gt;ssh-agent&lt;/code&gt; running as a systemd user service. One environment variable and the AI can reach every machine in my network — and, critically, &lt;em&gt;cross-reference&lt;/em&gt; what it finds on one machine with data from another. This investigation would have taken me hours of jumping between terminals. The AI did it in minutes, methodically testing hypotheses across three machines simultaneously. The infrastructure investment in proper SSH, DNS, and VPN paid off enormously.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
