Setting up Remote Access with Netmaker: A Step-to-Step Guide

Imagine you’re a developer at home, looking to access a Company portal, or even a database or Kubernetes cluster, at home. Better yet, it doesn’t even have to be an enterprise use-case; you might as well just be a homelabber looking to access movies on their NAS at home from their phone while on a camping trip! You wouldn’t be able to ssh into your router and install netclient as you usually would, which would mesh your whole local network all at once. This might be because of ISP restrictions; case in point, if you were using a router provided by a residential ISP like Altice or Comcast, you wouldn’t be able to see what was going on in there except through their interface.

The general idea is that you’re in some out-of-band location, and you don’t have a routing mesh handy, but you still want access services into your network. It sounds simple, if not downright obvious, but even many white-label SASE solutions like Cisco Umbrella or Palo Alto Prisma generally require you to purchase and maintain a separate routing device for out-of-band networks.

Modern mesh VPNs like Tailscale claim to get around this, but their solution is to install a custom client (i.e., the one you would otherwise install on your router) on every machine. This is often possible, but never ideal.

Introducing Remote Access Gateways/Clients

One of the core features of our WireGuard-based VPN solution, Netmaker, is convenient remote access in the above scenario.

It often gets annoying for corporate users to download a different client application for each system, especially consultants who might need access to multiple clients’ corporate networks from the same machine.

Case in point, one company might use Tailscale, another might use Cloudflare WARP, and a third might use pfSense; you don’t want to be downloading each custom client on each machine you need access from, and you shouldn’t have to either since it’s all WireGuard under the hood.

This is where we go the extra mile to make it easy on our users. Pretty much anything that runs WireGuard, which includes Windows, Mac, Linux, iOS, and Android, can be connected to the Netmaker virtual mesh and allowed to access internal services. We conform to the prevalent OSS standards while also providing unique bang-for-the-buck features, providing you with everything you need and nothing you don’t.

Creating a Netmaker Remote Access Gateway (RAC)

First, we have to configure a [remote access] gateway for remote access. A gateway as an object in Netmaker’s programming model designed to serve a logical group of clients with remote access. Effectively, all it does is forward traffic from the clients to the mesh network and back, but doing so securely and with respect to in-place ACL rules makes all the difference in the world.

The next step is to select a host for use as your gateway. You can pick any host in your mesh, including your Netmaker server itself, as long as it has a public IP address (i.e., it’s not behind a NAT).

Adding Clients to the Network

Next, we will add some clients to our remote access cloud. We simply have to configure the system as desired through the UI.

You can either manually specify client ID, public key, and DNS, or you can use the default DNS nameserver and let the system autogenerate your credentials. Unless specifically required in a custom configuration, we recommend you do the latter.

Our client is ready! We simply have to download the WireGuard configuration file directly or simply scan the QR code (if using the desktop app).

It should work well in standard WireGuard; we recommend the kernel implementation, but the userspace should functionally be the same.

Gateways for Remote Access vs. External Internet Connection

As a pro-only feature of Netmaker, we provide gateways for external internet access. Canonical internet gateways are, funnily enough, the dual of remote access gateways in a higher-order abstract category (we leave it as an exercise to the world’s math nerds to explicitly prove this!) Effectively, while RACs provide unmeshed nodes in the World Wide Web (www) with WireGuard access inside the mesh, internet gateways provide meshed networks with access to the external internet.

This is functionally similar to a Tailscale exit node. The idea is to allow a host anywhere in the mesh to function as an external-facing IP route. You can learn about the usage here; we won’t go over it explicitly, as it’s not the focus of this article.

The key here is that internet gateways also function as remote access gateways, except they (peculiarly) enable hosts in the mesh to connect to the internet via a gateway. This makes it possible to run a traditional VPN on any Netclient-enabled machine!

Conclusion

This tutorial aimed to showcase one of the more technically unique features of Netmaker; we find that our product shines in these unique little areas that you didn’t even know you needed because most other networking solutions overlook them!