{"id":79428,"date":"2024-06-24T11:52:22","date_gmt":"2024-06-24T03:52:22","guid":{"rendered":"https:\/\/version-2.com\/?p=79428"},"modified":"2024-06-26T17:22:58","modified_gmt":"2024-06-26T09:22:58","slug":"how-we-implemented-traffic-routing-in-meshnet-for-increased-security","status":"publish","type":"post","link":"https:\/\/version-2.com\/en\/2024\/06\/how-we-implemented-traffic-routing-in-meshnet-for-increased-security\/","title":{"rendered":"How we implemented traffic routing in Meshnet for increased security"},"content":{"rendered":"
\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

Traffic routing is a significant feature provided by NordVPN\u2019s Meshnet. Essentially, it allows any Meshnet-connected device, called a node, to become a VPN server for other nodes. To do this, the end user needs only to click a few buttons in the NordVPN app. Under the hood, however, we need to handle setup complexities in the code and ensure compatibility with platforms not inherently designed to operate as VPN servers.\u00a0<\/p><\/div><\/div>

\"\"<\/span>\"featured<\/span><\/p><\/div>

How a classical VPN server works<\/b><\/h2>

First, we should understand how a classical VPN server operates. Meshnet uses the NordLynx protocol, which is based on WireGuard<\/u><\/a>\u00ae \u2013 a simple, fast VPN that uses state-of-the-art cryptography<\/u><\/a>. For this article, we\u2019ll refer to WireGuard (wg) in our examples and graphics.<\/p>

A standard configuration would look like this:<\/p>

<\/p>

A standard VPN configuration.<\/p><\/div>

To arrive at this setup, a couple of things need to happen.<\/p>

First, let\u2019s establish a secure tunnel (purple dotted connection):<\/p>

  3. Private IP addresses (100.64.0.2, 100.64.0.1) are assigned to the client and server respectively.<\/p><\/div><\/li><\/ol>

    At this point, the client can ping the server using the IP address 100.64.0.1, and the server can ping the client at 100.64.0.2. All IP packets sent through the wgX interface are encrypted and sent via the global internet. The real path of the packet is something like this: wgC<\/b> \u2013(encapsulate)\u2013> lanC<\/b> \u2013> lanR <\/b>\u2013> netR <\/b>\u2013> netS <\/b>\u2013(decapsulate)\u2013> wgS<\/b><\/p>

    But to the OS, the wgX interface is just another network connection to where IP traffic can be routed, similar to a LAN router.

    <\/p>

    To the OS, a virtual interface is just like any other network connection.<\/p><\/div>

    Now if the client wants to conceal its real IP address, it can configure the routing table<\/u><\/a> to direct all default traffic through the wgA interface (some precautions are needed to avoid routing the encrypted traffic itself, but that\u2019s out of the scope of this article).<\/p>

    Meanwhile, the VPN server needs to be configured to function like a router, accepting incoming packets and forwarding them to their next destination. For this, two features are required:<\/p>

    IP forwarding<\/b><\/h3>

    In most network stack implementations, if a packet arrives on a network interface, it can only be sent out on the same interface. So when the server receives a packet from the wgS interface that\u2019s directed to an IP address outside the network\u2019s subnet, it is dropped.<\/p>

    Enabling IP forwarding changes this behavior. Now, when a packet arrives at a network interface, it is checked against the network\u2019s entire routing table. If another network interface provides a better match, the packet is forwarded to that interface.<\/p>

    Packet path on the server would look like this:\u00a0 \u2026 -> wgS \u2013(ip_fowarding)\u2013> netS -> \u2026<\/p>

    NATing<\/b><\/h3>

    IP packets arriving at the VPN server will have a private IP address like 100.64.0.2, assigned to the wgC interface. In most cases, these packets will be directed to a publicly routable IP address. After the packet gets forwarded to the netC<\/b> interface, it still can\u2019t be sent out, because its source address falls within the private network<\/u><\/a> range. The router uplink only deals with public IP addresses and wouldn\u2019t know which device is sending the packet.<\/p>

    As such, NAT (network address translation) is used. For every packet that has a unique source IP, port, and in some cases destination, a unique mapping is created in the NATing table.<\/p>

    For example, if a TCP packet comes from 100.64.0.2:AAAA, it would be mapped to a 192.0.2.1:BBBB address (here AAAA is the port used by software on the client device, and BBBB is a randomly assigned unused port on the server).<\/p>

    The TCP\u2019s packet\u2019s source IP and port would then be exchanged for NAT mapped values, checksum adjusted, and finally sent out on its merry way to the wider internet.<\/p>

    If another computer responds to this BBBB port, the NATing table is consulted and destination IP and port values revert to the original values before the packet is sent to the wgC<\/b> interface.<\/p>

    And that\u2019s all for a very rudimentary setup!<\/p>

    Supportable platforms<\/b><\/h2>

    The main challenge with these two requirements is that they limit the number of devices that can function as routers (apart from implementing a user space transport layer multiplexing\/demultiplexing logic).<\/p>

    Typically, if we want to set up IP forwarding and NAT, we need root\/administrator permissions. Most platforms with strong sandboxing<\/u><\/a> like macOS App Store, iOS, and Android do not provide official APIs to enable this.<\/p>

    That leaves 3 \u201cplatforms\u201d we do support:<\/p>

    Linux<\/b><\/h3>

    Linux is the easiest one of the bunch because it has everything we need already built in, and our NordVPN service, running as root, can set everything up.<\/p>

    macOS Sideload<\/b><\/h3>

    Unlike the App Store version (which I count as a separate platform), with macOS Sideload applications it\u2019s possible to create launchd<\/u><\/a> services that run with root permissions. This unlocks features that Darwin (the core Unix operating system of macOS) inherits from BSD<\/u><\/a> like ip_forwarding and pf (packet filter), which are used to set up NATing and filtering.<\/p>

    Windows<\/b><\/h3>

    Setting up IP forwarding is as trivial as a registry modification. However, even if Windows has an official NAT<\/u><\/a>, we found it difficult to use during testing. It does not properly work with Windows Home editions. Being primarily designed for use with Hyper-V<\/u><\/a>, a lot of undefined behaviors crop up when working with our custom adapter drivers. To work around this, we built and shipped our own implementation for NAT.<\/p>

    How Meshnet traffic routing works<\/b><\/h2>

    Now that we know how a regular VPN server looks and works, we can compare it to how it operates in Meshnet:<\/p>

    \"\"<\/span>\"Diagram

    A Meshnet VPN configuration.<\/p><\/div>

    The first interesting difference to observe is that, unlike a VPN server, in general, both Meshnet devices will be located in their local area networks.<\/p>

    And without Meshnet\u2019s NAT traversal<\/a> capabilities, turning a device into a VPN server for easy connection by other devices would be challenging.<\/p>

    The second difference is that your dedicated VPN server will usually have not one, but two NATing steps.<\/p>

    2. The server’s IP (device B) is then changed to the router’s IP.<\/p><\/div><\/li><\/ol>

      This unlocks some interesting behavior: If device A is your phone, and device B is your home PC, routing through B makes it appear to your network that your phone is actually your PC. This allows you to securely access your home network without needing API services hosted on a public server.<\/p>

      And if you use a service that only allows access from your home network, it becomes impossible to tell whether the network messages are coming directly from your home PC or a device routing through it.<\/p>

      At this point, if you are even slightly inclined towards security, some alarm bells may be ringing.<\/p>

      Security considerations<\/b><\/h2>

      Traffic routing is a very powerful feature:<\/p>