Giving the Netclient Networking Functions

Overview

Now that you have added Nodes to your server and appropriate networks, it is time to configure the nodes that require specific network functions. We’ll walk through all the various network functions you may wish to set up here.

Keep in mind that a single Node can serve multiple functions. A single Node can be a Gateway that serves both User and Config File Traffic, Auto-Relays traffic between Netclients, and also configured with Egress to subnet ranges, or configured as an Internet Gateway. It will all come down to your scenario and topology.

The Default Endpoint

For SaaS, a Managed Endpoint is included, which can serve many of these purposes when you don’t know what to use. For On-Prem, a Node is deployed on the server which can serve the same purpose.

Consider this your default endpoint for routing. There are reasons to choose Nodes in other locations (latency, redundancy, access restrictions), but the default endpoint is a good place to get started. It will already be set as a Gateway, which will serve several purposes:

• Auto Relay: Provides higher availability for connections, acting as a fallback when peer-to-peer connections fail.

• User Traffic: The default endpoint is ideal to serve as an entrypoint for user traffic, because the Netmaker server is typically deployed in a way where the endpoint will be easily accessible globally.

• WireGuard Config files: For a similar reason, the default endpoint works well for generating config files, if necessary.

• Static Relay: if you notice a Node with reachability issues, using the default endpoint as a Relay for this host is a good idea.

• Internet Access: If you're looking to set up a simple full tunnel VPN, you can use the default endpoint, editing its Gateway settings to make it an "Internet Gateway".

Required Configurations by Topology

If you are looking to generate a specific topology, there are related functionalities you will need to give your Netclients.

Peer-to-Peer

By default, Nodes form a peer-to-peer network with each other. Any machine with the Netclient deployed should have direct access to the other machines with the Netclient deployed. For certain networks, this may be all you need — for instance, if you have some devices in various, scattered networks which need to communicate with each other over a secure channel.

Hub-And-Spoke

You may want some, or all, of your Nodes to communicate via a “Hub”, e.g. a Gateway. For instance, if operating in a restricted environment, or for data security reasons. This can be done by setting a Node as a Gateway, and selecting which other Nodes it will manage traffic for.

Full-Tunnel

To create a Full-Tunnel VPN, set a Gateway as an Internet Gateway, and select which Nodes it will forward traffic for. Users and Config Files that use the gateway will also by default have their internet traffic routed through the device.

Remote Access

For accessing remote environments like office LANs or cloud VPCs, you will most likely use two Nodes: one (or more) acting as the Gateways, and one (or more) acting as a Egress to the local network(s).

Site-to-Site

If you would like to forward traffic between two or more local networks, such as offices or data centers, this can be accomplished via two distinct methods. The configuration for each is very different:

1

Nodes with Egress

Deploy a Node in each Site, and set it as a Egress to the local network. Then configure forwarding rules (router configuration or other method) so that local devices push traffic destined for the other sites via the local Node. For example, you could change the default gateway in the local network to use the Node.

2

Config Files with Egress

A single Gateway can serve as the “Hub” of a Hub-and-Spoke shaped site-to-site network. For each site, generate a WireGuard config file and specify the Egress ranges. Apply the config file to a router at each local site; traffic between the sites will then flow through the Gateway and out to the other sites via WireGuard.

Gateway Setup

In most scenarios, you are going to want one or more Gateways. The Gateway serves two purposes:

• The Access Point for the Users: Users, when they log into the VPN, will connect via a Gateway. Users can manually select a Gateway, or simply connect, and the fastest Gateway will be selected automatically. In a global deployment, you will want to deploy multiple Gateways in different regions for optimal performance.

• A Gateway for Static WireGuard Configuration Files: The Gateway allows you to create and manage WireGuard config files which can be applied directly to devices. If you wish to add a router or IoT device to your network which cannot run the netclient, generate a WireGuard config file and apply it to the device. Access to and from the device will then go through the Gateway.

• A Relay between Netclients: Netclients (Nodes) can be assigned to a Gateway, in which case their traffic will route via the Gateway. There is also an Auto Relay feature of the Gateway, which will do this automatically in the case of connection failure.

• A Gateway to the Internet: By toggling on the Internet Gateway feature of the Gateway, it will forward all connected traffic (which does not have a destination inside the VPN) out to the internet.

Configuring the Remote Access Gateway

Setting a Node as a Gateway is simple. Go to the “Gateways” tab of your network, and create a Gateway from an existing Node. A few considerations:

1

The Gateway must be deployed on a Linux host (or docker container).

2

The Gateway should be accessible by all remote devices which will use it — typically meaning it is in a public environment (cloud) or has appropriate routing set up for the IP and Port of the netclient.

3

The Gateway should be stable: ideally a dedicated, static IP address (not floating), consistent Port, no NAT restrictions, and not on a workstation or device which may turn off easily.

Once the gateway is created, config files and users can be added. Both will be discussed in later sections of the guide.

Egress

For a typical remote access scenario, you will want one or more Egress routes. The Egress functionality forwards traffic via specified nodes to specified external IP addresses in a remote network (for example, an office LAN, cloud VPC, or edge site). Multiple Egress ranges can be configured per-network, and multiple Nodes can act as Egress for the same route, to provide redundancy and high availability. The fastest route will always be selected.

A more advanced use case is to use Egress to configure site-to-site traffic. However, local devices must be configured to forward traffic via the local node, so routes must be configured on the local network after egress is deployed.

Configuring Egress

Like the Gateway, a Egress must be configured on Netclients running in Linux or Docker.

To configure: go to the Egress tab, click create, and specify the routes. Then add the devices which will forward the traffic. The specified nodes will begin forwarding traffic from the VPN network to the specified ranges automatically.

Setting Up Site-to-Site with Egress

Egress makes local networks accessible from the VPN. But to make local networks reach the VPN or each other, these routes must be advertised on the local network, to tell those devices to route the remote network CIDRs via the local egress node.

Example scenario:

• Netmaker VPN: 100.10.10.0/24

• Cloud VPC: 172.98.52.0/24

  • Netclient with Egress deployed

• Office LAN: 192.20.0.0/16

  • Netclient with Egress deployed on 192.20.10.15

Assume you want the Office Lan to reach the Cloud VPC and the Netmaker VPN. You must advertise routes on the LAN so that devices route both 100.10.10.0/24 and 172.98.52.0/24 via 192.20.10.15. This can be done on the local firewall or a variety of other methods.

After this, the egress node will forward requests to the remote networks from the local devices.

Next Steps

In the next section, we’ll discuss static clients, where you might use them, and how to add them to your network to fill in any remaining gaps before granting users access to the network.