{"id":65187,"date":"2023-03-27T17:40:53","date_gmt":"2023-03-27T09:40:53","guid":{"rendered":"https:\/\/version-2.com\/?p=65187"},"modified":"2024-09-13T16:31:23","modified_gmt":"2024-09-13T08:31:23","slug":"reaching-beyond-1gbps-how-we-achieved-nat-traversal-with-vanilla-wireguard","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2023\/03\/reaching-beyond-1gbps-how-we-achieved-nat-traversal-with-vanilla-wireguard\/","title":{"rendered":"Reaching beyond 1Gbps: How we achieved NAT traversal with vanilla WireGuard"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Nord Security engineers have been hard at work developing Meshnet, a mesh networking solution that employs the WireGuard tunneling protocol. Here are the technical details on how we tackled the challenge of optimizing Meshnet\u2019s speed.<\/p>

\"\"<\/span>\"Blog

Meshnet is powered by NordLynx, a protocol based on Wireguard<\/a>. WireGuard is an excellent tunneling protocol. It is open, secure, lightweight, lean, and \u2013 thanks to the in-kernel implementations like in the Linux kernel<\/a> or the Windows NT kernel<\/a> \u2013 really, really fast.<\/p><\/div>

\"\"<\/span>\"natblog1\"<\/span><\/p>

An iperf3 speed test between NordVPN\u2019s staging VPN servers with a single TCP connection tunneled over WireGuard.<\/p><\/div>

At the heart of it is \u201ccryptokey routing<\/a>,\u201d which makes creating a tunnel almost as easy as tracking a few hundred bytes of state. So having hundreds or even thousands of tunnels from a single machine is feasible.<\/p>

These properties make WireGuard a very appealing building block for peer-to-peer mesh networks. But before getting there, a challenge or two must still be overcome. So let\u2019s dig into them!<\/p>

Ground rules<\/b><\/h2>

Here are ground rules to help us to better weigh tradeoffs. First, privacy and security is a priority, so any tradeoff compromising end-to-end encryption or exposing too much information is automatically off the table. Second, speed and stability is one of the most important qualities of Meshnet. Finally, to cover all major operating systems (Windows, Android, iOS, macOS, and Linux), any ideas or solutions must be implementable on those platforms.<\/p>

So here are the ground rules:<\/p>

Rule #1<\/b><\/p>

Everything will be end-to-end encrypted. Any user data passing between devices must be inaccessible to anyone else \u2013 even to Nord Security itself.<\/p>

Rule #2<\/b><\/p>

No mixing of the data plane (i.e., the code that processes packets) and control plane (i.e., the code that configures the network), if possible. That\u2019s because any additional logic (e.g., NAT traversal, packet filtering\/processing) added to the WireGuard will slow it down.<\/p>

Rule #3<\/b><\/p>

No solutions that target a single WireGuard implementation. Remember those fast in-kernel implementations? In order to reach high throughput everywhere, we must be able to adapt to the intricacies of every platform.<\/p>

Great! Now let\u2019s get cracking!<\/p>

NAT traversal 101<\/b><\/h2>

Every peer-to-peer application (including Meshnet) has a NAT traversal implementation at its heart. While this is a rather wide topic (just look at the amount of related RFCs: RFC3261<\/a>, RFC4787<\/a>, RFC5128<\/a>, RFC8489<\/a>, RFC8445<\/a>, RFC8656<\/a>\u2026), the core principle is quite simple: NATs are generally designed to support outgoing connections really well.<\/p>

They achieve this by forwarding any outgoing packets while remembering just enough information to be able to discern where and how to forward incoming response packets whenever they arrive. The exact nature of this information and how it is used will determine the type of the NAT and its specific behavior. For example, Linux NATs are based on the conntrack kernel module and one can easily check the state of this information at any moment using the conntrack -L command.<\/p>

1<\/span><\/p>

$ <\/span>sudo<\/span> conntrack -L <\/span><\/div><\/div>

2<\/span><\/p>

tcp <\/span>6<\/span> 382155<\/span> ESTABLISHED <\/span>src<\/span>=<\/span>192.168<\/span>.3.140 <\/span>dst<\/span>=<\/span>172.217<\/span>.18.3 <\/span>sport<\/span>=<\/span>60278<\/span> dport<\/span>=<\/span>443<\/span> src<\/span>=<\/span>172.217<\/span>.18.3 <\/span>dst<\/span>=<\/span>192.168<\/span>.3.140 <\/span>sport<\/span>=<\/span>443<\/span> dport<\/span>=<\/span>60278<\/span> [<\/span>ASSURED<\/span>]<\/span> mark<\/span>=<\/span>0<\/span> use<\/span>=<\/span>1<\/span><\/div><\/div>

3<\/span><\/p>

tcp <\/span>6<\/span> 348377<\/span> ESTABLISHED <\/span>src<\/span>=<\/span>192.168<\/span>.228.204 <\/span>dst<\/span>=<\/span>35.85<\/span>.173.255 <\/span>sport<\/span>=<\/span>38758<\/span> dport<\/span>=<\/span>443<\/span> src<\/span>=<\/span>35.85<\/span>.173.255 <\/span>dst<\/span>=<\/span>192.168<\/span>.228.204 <\/span>sport<\/span>=<\/span>443<\/span> dport<\/span>=<\/span>38758<\/span> [<\/span>ASSURED<\/span>]<\/span> mark<\/span>=<\/span>0<\/span> use<\/span>=<\/span>1<\/span><\/div><\/div>

4<\/span><\/p>

..<\/span>..<\/span>..<\/span><\/div><\/div>
\u00a0<\/pre><\/div><\/div><\/div>
This great RFC4787<\/a> goes into a lot of detail about NAT behavior in general.<\/p>
While outgoing connections are handled transparently, incoming connections can be trouble. Without outgoing packets forwarded first (and consequently without the conntrack information), NATs simply do not have any clue where to forward packets of incoming connections and the only choice left is to drop them. At this moment, we finally arrive at the core part of any peer-to-peer connection establishment:<\/p>
Suppose you shoot a packet from both sides of the peer-to-peer connection at each other roughly at the same time. In this case, the connection will appear to be \u201coutgoing\u201d from the perspective of both NATs, allowing hosts to communicate.<\/p><\/blockquote>
Let\u2019s unpack it a bit:<\/p>