IntroductionCopied!

The purpose of this section is to provide an overview of various components and features within Netmaker, which are helpful to understand in the context of building your network.

Netmaker uses a lot of terminology that may sound unfamiliar, so please refer back to this section if you are having trouble understanding what exactly a particular word or feature means.

By the end of this section, you should understand the important pieces of Netmaker and what they mean in the context of networking and VPNs generally.

Netmaker ComponentsCopied!

Regardless of your scenario, you will be plugging together different components of Netmaker,  much like lego bricks. While there are many different scenarios, the same components of Netmaker are used to bring them all together. So, it is helpful to gain a general understanding of these components and how they work together.

Netmaker ServerCopied!

All scenarios start with having a Netmaker server. This can be deployed either On-Prem or in our Cloud environment (SaaS). For standard scenarios we recommend SaaS, since it is the easiest way to get started. If you have specific data privacy requirements or need custom OAuth, then you will want to deploy On-Prem. We will cover this in more detail in the next section on server deployment.

NetworkCopied!

In all scenarios, you will need at least one network. A Network in Netmaker is  a VPN. It’s a logical, virtual subnet, that represents a system of connections between devices, acting as a group. Each member of that group gets an IP within the virtual network. In Netmaker, you can have many networks, to manage different scenarios and keep them segmented. 

A Network can be IPv6, IPv4, or both (dual-stack). You will want multiple networks if you are setting up different network scenarios, providing access to different sites, or  segmenting access between different groups of users or devices. 

NetclientCopied!

The netclient is the headless agent that runs on servers and manages VPN settings, receiving instructions from the coordination server (Netmaker). This is the “local VPN configurator” agent of Netmaker, and can be configured to forward traffic, acting as an Egress Gateway, Remote Access Gateway, Internet Gateway, Failover Server, or Relay, which is why we need it. All scenarios require at least one Netclient, but many basic scenarios require only one or two. 

Host (Node)Copied!

Netclients added to the network appear as “nodes” (or Nodes) in the system. A node can live in multiple networks, meaning, for example, a netclient running on a server in your cloud could function as a Relay or Remote Access Gateway, for multiple networks, while keeping traffic segmented and secure between the two. Because of this, a node has two scopes, at the global level and network level. Global Node settings include things like the hostname and MTU, and take effect across networks. Network-Scoped settings include things like the virtual address on the network, and gateway settings (like setting it as a Remote Access Gateway). This allows a single device to act as a gateway in multiple networks, while maintaining segmentation.

Remote Access GatewayCopied!

The Remote Access Gateway is a powerful feature which can be applied to nodes in a network. All remote access scenarios, and many site-to-site scenarios, require a Remote Access Gateway. The Remote Access Gateway enables us to do several things:

• Allows users to authenticate and access the network from their devices using the Remote Access Client.

• Allows access to and from any device that supports WireGuard using a static VPN config file.

• Allows access to and from sites via routers configured with a WireGuard VPN config file. 

At its core, the Remote Access Gateway manages “VPN Config Files”, which are WireGuard-compatible config files that can be run on most devices. For users, these files are generated dynamically via the Remote Access Client, and for devices and routers, static files can be generated, customized, and applied to the devices.

Egress GatewayCopied!

Many scenarios require accessing a subnet at a site, which can be done using an Egress Gateway. This is done by setting a Node as an Egress Gateway, and specifying which IPs and CIDRs will be accessed via the node. The node will then begin to automatically forward traffic into the local network. Alternatively a static config file can be used, for situations like routers. There are pros and cons to be considered with both approaches, collectively referred to as  “local gateways,” however, for most standard use cases, we recommend using an Egress Gateway to access local sites.

Internet GatewayCopied!

The internet gateway is a configuration very similar to the Egress Gateway, with one key difference: It creates a full tunnel VPN. If you want your users to access the internet via a node on the network (for instance, routing internet traffic through the office), use the Internet Gateway feature.

Relay ServerCopied!

In some scenarios, you will want an intermediary server to route traffic between particular devices. For example, if there is a restrictive CGNAT on the office network, routing traffic through a Relay will make the network more reliable. The relay acts as a dedicated node for routing traffic between particular nodes on the network.

Failover ServerCopied!

A failover server acts similarly to a Relay, but works automatically. With a Relay, you specify which machines will route traffic via the relay, and traffic will always go through the Relay. With Failover, devices will detect if traffic is not being sent, and if there is a disruption, route via the Failover instead.

Additional TerminologyCopied!

Outside of Netmaker, there are some standard components that come into play when configuring your network. It is important to have an understanding of these key components.

Public Linux ServerCopied!

Most scenarios will require at least one linux server which is public-facing. This means it is deployed in a cloud environment, or you have configured routing/firewall rules in a data center or office network so that the server has a reliable endpoint for the VPN at <public ip>:<port>. This server typically acts as Remote Access Gateway, Egress Gateway, Relay Server, Internet Gateway, Netmaker Server (for on-prem setups), or some combination of the four!

Router ConfigurationCopied!

If you want traffic to go through a router, you will have to configure the router. The specifics will depend on your scenario, but most likely, the router will need to be configured with WireGuard and a VPN Config File, which is attached to a Remote Access Gateway. Alternatively, you may need to set up rules on the Router to route traffic through a local device that is running the netclient.

Routing ConfigurationCopied!

If you are configuring a network so that devices can route traffic through the VPN, without needing the VPN client, then they will need to have routing rules that tell them where to send traffic. This must either be done on the router (as explained above), or, if that is not an option, by configuring all devices on the network with additional routing rules. For instance, adding a routing rule to your VPC to send VPN-bound traffic via the device in the environment running the VPN client.

WireGuardCopied!

When integrating any device into the network, it must run WireGuard. Our installers install WireGuard automatically, but for non-native and router device integration, they must run WireGuard. Most devices support WireGuard, and you may need to learn how to configure WireGuard on specific target devices.

VPN Client TypesCopied!

Netmaker has three primary ways to add devices and users to the VPN. Each has specific uses depending on the networking scenario and target devices.

Planning Your SetupCopied!

QuestionsCopied!

Here is a list of questions that will help you determine what you need for your setup. By answering these questions, you’ll understand which configuration options you must understand as you move through the guide. Below, we’ve also provided a flow chart which similarly helps you to determine what you need.

Server Deployment: SaaS is the easiest way to get started, but review the flow chart in the next chapter to see if you may want to deploy on-prem instead.

Configuring Local Access:

• Are you configuring access to a site?

  • If so, you will likely deploy a Netclient in the local environment on a Linux box and set as an Egress Gateway or Internet Gateway

• Do you want access from the site as well?

  • Does the site have a router to use as the local gateway?

    • If the router has a compatible WireGuard plugin, you will generate a VPN Config File on your Remote Access Gateway and deploy on the device.

    • If the router is not compatible, you may be able to deploy an egress gateway, and set routes via the router to route through the gateway (deployed on a local linux server)

• If deploying a Netclient, is the environment’s network very restricted?

  • If so, you likely need another Node/Netclient in the cloud to act as a Relay to this client.

• Are you creating a Split Tunnel, or Full Tunnel, VPN for your users?

  • Split Tunnel is provided via Egress, Full Tunnel via Internet Gateway

Configuring Remote Access

• Do you need to configure user access to the VPN? If so, you want a Remote Access Gateway.

• Do you need to add non-native devices like routers to the VPN? If so, you want a Remote Access Gateway.

• Can you set up a linux server or docker container which is reachable through the VPN over the public internet, to act as a Remote Access gateway?

  • If it is behind a router or gateway, you will need to set up routing rules so that <public ip>:<port> will route to the linux server.

Routing Rules (Remote access from, Site to Site)

• If you want to configure access from a site and cannot deploy on the Router, you will need to configure static routes for all machines in the environment, after deploying a netclient acting as an egress gateway.

Segmentation

• Do you need to segment access based on users, devices, clients?

  • If so, you will need to design your setup with multiple networks and/or gateways.

Client Access

• Do your users need on-demand access, or should the VPN be always on?

  • If on-demand, provide remote access client

  • If always-on, configure devices with a static WireGuard config file.

Flow ChartCopied!

GlossaryCopied!

Some terms will appear repeatedly throughout this guide. If you are unfamiliar with these terms, you can refer back to this glossary to get some context.

Authentication & Authorization (OAuth / OIDC/ 2FA): Methods for users to securely identify themselves, and be granted access to a network. Typically integrated with a company’s identity service like Microsoft 365.

VPN Config File: A static WireGuard config file, generated from a Remote Access Gateway, which can be run with WireGuard on any device, making it accessible from, and able to access, the Netmaker network. 

Clients: Devices added to the network using a Config file or using the Remote Access Client, via a Remote Access Gateway

Remote Access Gateway: A device (managed by netclient) which routes traffic to and from “Clients”.

Egress Gateway: A device (managed by netclient) which routes traffic to remote IP addresses outside the VPN. For instance, a local office network, a cloud VPC, or specific Endpoints

Internet Gateway: A device (managed by netclient) which routes traffic to the internet from devices in the VPN. For instance, route internet traffic via a machine in the local office network.

Endpoint: A single device, typically (but not always) with a single IP address. Represented by a Node / Netclient.

Node: In Netmaker, a Node is a physical device, which has been enrolled with the Netmaker server via Netclient. A node can be a part of one or more VPN networks.

Local Gateway: A machine routing traffic to the local network from the VPN. This can be either an “Egress Gateway”, which requires running the Netclient, or a manually configured “Client” via VPN Config File, which requires just WireGuard

Netclient: An agent, binary, and service that runs on a device in order to manage VPN settings and  integrate it into the VPN network created by Netmaker. It receives updates automatically from the server and configures WireGuard (the VPN protocol). The netclient can also set the device as a “gateway” in order to route traffic to/from remote devices.

Netmaker (server): The control plane of Netmaker. Typically interacted with via the Dashboard (UI) in order to create, configure, and manage virtual networks. Often referred to as the “server.”

Remote Access: Securely accessing an ip address, website, or computing resource from outside of the local network. For instance, if you have a service running in the cloud, accessing it from your home computer.

Remote Access Client: Netmaker’s remote access solution, which end users install on their devices to access remote sites, via a gateway, typically using some form of authentication.

Router / Firewall: A device sitting in front of the site, that routes traffic to, from, and between devices at the site, and typically also blocks certain traffic into/out of the network.

Site: A location, typically with its own local network. For instance, devices on an office network can reach each other over a local network, without having to go over the internet.

Subnet: A range of ip addresses, typically on a private or local network, which have direct access to each other.

VPC: “Virtual private cloud” - A private subnet within a cloud environment, where you can deploy machines with access to each other, typically deployed in a way so that they are inaccessible directly from the public internet.

WireGuard: A VPN protocol used to encrypt traffic between devices. This is the protocol used by Netmaker, via the netclient (which manages WireGuard) or via the Clients / Client Config files, which are unmanaged WireGuard connections to the network. WireGuard is a supported software on most devices, including phones, computers, and routers, and typically has software available for controlling it (like the netclient).

Scenario-Specific ConsiderationsCopied!

Beyond the general type of VPN you are creating, you probably have specific requirements that will affect your setup. All of these can be configured with Netmaker, but you should be aware of your requirements ahead of time:

• Adding a router to the VPN

• Using a Linux device to route traffic to the local network

• Configuring local routing rules to route traffic via a VPN client, so that other devices on the network do not require the VPN client

• Granting access only to specific devices on the local network, not to the entire network.

• Segmenting access based on user groups

• Creating a split-tunnel or full-tunnel VPN, or combining the two

• Configuring private DNS on the devices

• Integrating a local auth provider

• Configuring always-on, on-demand, or temporary (expiring) access to the network

We will cover all these and more throughout the guide.

Next StepsCopied!

Now that we’ve covered the basics, let’s get into setting up Netmaker, starting with the Netmaker server itself, and how to deploy it.