<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Network on Matt Ellis</title><link>https://matt-ellis.dev/tags/network/</link><description>Recent content in Network on Matt Ellis</description><generator>Hugo</generator><language>en-GB</language><lastBuildDate>Tue, 19 May 2026 09:00:00 +0000</lastBuildDate><atom:link href="https://matt-ellis.dev/tags/network/atom.xml" rel="self" type="application/rss+xml"/><item><title>A week debugging WireGuard through an ER605</title><link>https://matt-ellis.dev/rambles/wireguard-er605/</link><pubDate>Tue, 19 May 2026 09:00:00 +0000</pubDate><guid>https://matt-ellis.dev/rambles/wireguard-er605/</guid><description>&lt;p&gt;Started the week thinking this would be a two-hour job. A week later I have WireGuard working and a much better understanding of why consumer routers make NAT traversal so much more painful than it needs to be.&lt;/p&gt;
&lt;p&gt;The short version: the ER605 does symmetric NAT, which means the source port changes on every outbound connection. WireGuard&amp;rsquo;s handshake expects the port to stay consistent long enough to complete, and on a symmetric NAT box it often doesn&amp;rsquo;t. The fix was to set up the WireGuard endpoint on a VPS I already had, and use that as the relay rather than trying to punch through from the ER605 directly.&lt;/p&gt;</description></item></channel></rss>