Planning Your Hosts and Clients

Now that we have a network (or networks) configured for our VPN, it is time to start adding in the devices that will make up the networks. Before we do this, it is helpful to understand what needs to be deployed, and where. For instance, do you need a Host in the office on a Linux server, or a Client deployed on a Router? Do you need a Relay in the cloud?

This part of the guide will provide clarity on what devices you will need to add to your network, how you will need to add them, and what other supporting features may be necessary. By the end of this guide, you should have a good mental picture of which devices you are going to add, and whether they will require a Host or a Client.

Diagram Walkthrough

Let’s walk through this diagram to get an idea of the difference between Hosts and Clients, and some of the actions they may perform, depending on the use case.

‍

In the legend you’ll note that Clients are diamonds, and Hosts are squares. External environments (outside the VPN) are clouds.

Clients

All Clients must be attached to a Remote Access Gateway. A Host can be set as a Remote Access Gateway in the Netmaker Dashboard. A Host must run Linux, and have a reliable public IP to act as a Remote Access Gateway. Then, Clients can be generated which are attached to the gateway, which have access to and from the network. Clients are simple, static, WireGuard configuration files.

1. Remote Access Client

Users can be added to a Remote Access Gateway, which allows them to log into the VPN using a local application called the Remote Access Client. This app runs on desktop and mobile devices. After logging in, this app allows users to generate their own Client config files on the server, and then applies these configurations locally. This Client allows the user to access the VPN network via the gateway.

For User devices, since they are generating their own config files, you can ignore device setup. However, note that you will need a Remote Access Gateway. In fact, you may want multiple gateways, depending on the scenario. 

(2-3) Router and Office LAN

Clients can also be generated by administrators to apply directly to devices. One such use case is for integrating a router.

When generating a Client, you can add optional fields, such as address ranges, which will be applied to the configuration. 

Consider you have an office router that supports WireGuard, and a LAN address range of 192.168.1.0/24. You can add this field to your Client configuration file.

After creating this Client, you can apply then apply the configuration settings to your router, using a WireGuard plugin (in this example, we have a PFSense router). This will allow your LAN to have access to the VPN, and VPN to have access to the LAN, via the Router and Remote Access Gateway.

(4) IoT Device

If you have any other devices that support WireGuard, but do not support the Netclient (remember, the Netclient only runs on Windows, Linux, and Mac), you can add these devices to the network by generating a Client, and applying it to the device using WireGuard. Such a device might be machinery, a robot, a router, or just an unsupported operating system like BSD. Such devices likely just act as an endpoint in the network, which either needs to access the VPN, or needs to  be accessed by the VPN (or both).

It is worth noting that you may also want to do this just to provide an always-on config file for users which is not managed by the local user. For instance, you can generate a file, apply it to someone’s laptop, and they will always be connected to the VPN as long as the file is active.

Hosts

All devices added to Netmaker via netclient become Hosts. Every network needs at least one host in order to exist. Hosts are automatically synced across all networks which they are in, and receive updates as Hosts and Clients are added, removed, and modified within the networks.

Once added to a network, an administrator can set a Host as a Remote Access Gateway, an Internet Gateway, an Egress Gateway, or a Relay. A Host can act as a combination of these features at once. For instance, a Host can be both a Remote Access Gateway and an Internet Gateway.

A Host may also just be an endpoint on the network, which users need to access, or which needs to access other endpoints via the network. For instance, a server in your data center.

Typically, different Hosts perform different functions depending on their location. For instance, a host in the cloud is suitable as a Remote Access Gateway or a Relay, while a host in the local office network is suitable as an Egress Gateway for the LAN.

(5) Remote Access Gateway

Most use cases require a Remote Access Gateway. Here, the gateway is routing traffic to and from the three attached Clients (1, 2, 4), as well as accepting forwarded traffic to and from the Office LAN (3) behind the Router client (2).

While this network has one RAG, some networks may have multiple. This would allow an administrator to segment access across different user groups, or to provide multiple access points depending on location.

(6) Relay

Here we have a Host acting as a Relay, routing traffic to and from the Endpoint (7). Like the Remote Access Gateway with Clients, a Relay routes traffic to and from specified Hosts. This is useful if a Host is in an unreliable or restricted environment, like an office behind CGNAT. It makes access easier and more reliable. A Relay can also be useful as a chokepoint for controlling where and how traffic enters or exits a particular environment.

Multiple devices can be deployed behind a Relay.

This relay likely exists in the Cloud, the preferred environment for such Hosts. The administrator probably could have set the Host #5 as a relay (in addition to an RAG), which would remove the need for an additional machine.

(7) Endpoint

Some Hosts are simply endpoints that need access to or from the network. For instance, a server running a database, which developers need to access. There is no need for traffic forwarding or other advanced routing features, this device just needs to be an endpoint in the network, with a virtual IP address. This is the default state of a Host in the network.

In this scenario, the administrator chose to Relay this device via Host #6, likely because it is in a restricted environment, which would make it a “Relayed” host. 

(8-10) Egress Gateway / Internet Gateway

Here we have a Host configured as both an Egress Gateway and an Internet Gateway. This means it is routing traffic a local network (9) via one interface and the general internet (10) via its default interface. This means the Hosts and Clients in the network will reach the internet via this device, as well as be able to reach the Cloud VPC.

In most scenarios, it is preferable to use different Hosts as the Egress and Internet Gateways.

What Hosts and Clients Will You Need?

Now that we’ve gone through this example, think about what Hosts and Clients you will need in your network.

Hosts

You will need at least one Host in your network. As an example of a “one host” network, consider Remote Access to the internet from User devices. In such a use case, you might use your Netmaker Server (on-prem) or Managed Endpoint as the Remote Access Gateway, and also as the Internet Gateway. Users will access the internet through the gateway using Clients, so, this network has only one host.

Now, let’s say instead of the internet, these users need to access a local LAN. In this case, you likely also need a Host deployed in the LAN environment to act as an Egress Gateway. If users need to access LAN’s in different environments, you will need to deploy a Host in each of these environments. A Host can only act as an Egress for local networks which it is able to access.

Or, maybe you want internet traffic to go out through a device in the office, in which case you will need to deploy a Host in the office instead of using your Cloud machine.

If you have some particular endpoints you want to access without using Egress, like an EC2 instance, or a server running a database, you will want to deploy additional Hosts on these devices directly. This keeps all traffic within the VPN, rather than forwarding traffic to endpoints via an Egress gateway, in which case you are accessing the local IP of the device on the local network.

If your endpoint or egress is in a restricted environment, you may want an additional Host deployed to act as a Relay. It can be helpful to have Relays which are geographically closer to your endpoints. For instance, if your office is in Amsterdam, using a cloud-hosted Relay in Western Europe. You can have multiple Relays serving different relayed Hosts.

What Clients will you Need?

If you have endpoints which need access to or from the network, which do not support the netclient, you will want to generate Clients and apply them to these devices. This could include Routers, in which case you may configure additional addresses on the Client, to make the whole LAN accessible to or from the device.

For users access via Remote Access Client, we will cover this in a later section, but you do not need to generate clients in advance.

However, you do have the option to generate Clients and send them to users for static access, which is useful for some scenarios, such as always-on access to the network.

In Context of Multiple Networks

We are considering all of this within the context of a single network. However, it is worth considering that a Host can be a part of multiple networks, and can serve different functions in different networks. For instance, a Host can be an Egress in Network A, and just an Endpoint in Network B. A Host can also be a Remote Access Gateway in multiple networks, and route the traffic for these clients separately and keep the traffic segmented.

For instance. You might have:

Network 1:

• Host A acting as a Remote Access Gateway
• Host B acting as an Egress to the office

Network 2:

• Host A acting as a Remote Access Gateway (again)
• Host C acting as an Egress to the cloud

A Host within multiple networks will not route traffic between networks. You can think of it as a different “virtual” host in each network. This is more obvious when you view the Settings of a Host within your dashboard. There are two places for Host settings, at the Network level, and the Global level. A Host has the same “public IP” across all networks (a Global setting) but different “private IPs” (a Network setting).

This is great for when you want a Host to serve multiple functions across different networks. For example, a Host can be a Relay in multiple networks, but will not relay traffic between the networks. A Host can be a Remote Access Gateway in multiple networks, but Clients from Network A will not be able to access endpoints in Network B.

Next Steps

By this point you should have a good understanding of what you will need to deploy to set up your network. Once you know which devices will serve as the foundation of your network, it is time to move on to add these devices into your network and configure them for their required role.

We will start with the non-user devices, which are the Endpoints, Routers, Relays, and Gateways of your network. After that, we will move on to configuring user access.