Giving the Netclient Networking Functions
Overview
Now that you have added Hosts to your server and appropriate networks, it is time to set your Hosts according to the various functions they are going to perform. We’ll walk through all the various network functions you may wish to set up here.
Once you have an idea for how you want your network to look, you can begin to set Hosts according to what functions they should serve. Keep in mind that a single Host can serve multiple functions. A single Host can be a Relay, a Failover, an Egress Gateway, and a Remote Access Gateway all at once! It will all come down to your scenario which should act as which.
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 Host is deployed on the server which can serve the same purpose.
Consider this your default endpoint for routing. There are reasons to choose Hosts in other locations (latency, redundancy, access restrictions), but unless you have a good reason, you can go ahead and use that “default” endpoint to serve some of these roles. In standard use cases, you will use the default endpoint as a:
Failover Server: set the default endpoint as a Failover for your networks, which will give you higher availability when peer-to-peer connections fail.
Remote Access Gateway: the default endpoint is ideal to serve as a Remote Access Gateway because the Netmaker server is typically deployed in a way where the endpoint will be easily accessible globally.
Relay: if you notice a Host with reachability issues, using the default endpoint as a Relay for this host is a good idea.
Example Topologies
Peer-to-Peer
By default, Hosts 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 Hosts to communicate via a “Hub”, e.g. a Relay. For instance, if operating in a restricted environment, or for data security reasons. This can be done by setting a Host as a Relay, and selecting which other Hosts it will forward traffic for.
Full-Tunnel
To create a Full-Tunnel VPN, set a Host as an Internet Gateway, and select which Hosts it will forward traffic for. For user Full Tunnel VPNs, you can create an Internet Gateway and a Remote Access Gateway (same or different devices) so users can access the internet over the VPN.
Remote Access
For accessing remote environments like office LANs or cloud VPCs, you will most likely use two Hosts: one acting as the “access point” or Remote Access Gateway, and one (or more) acting as an Egress Gateway 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:
Remote Access Gateways and WireGuard Config Files
A single Remote Access 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 local IP ranges. Apply the config file to a router at each local site; traffic between the sites will then flow through the Remote Access Gateway and out to the other sites.
Failover Servers
A good first step for any network you create is to specify a failover server. The failover server will act as a backup for connections when peer-to-peer is not working. When peer-to-peer connections fail, a failover server will automatically begin routing the traffic.
For a given network, on the Hosts tab, click the "There's no failover host present in the network. Set one for redundancy, in case of failure." warning message switch named “Set Failover Host” to set a host as the Failover for the network. This should be a machine that is not in a private environment and is easily reached by all hosts in the network.
Remote Access Gateways
In most scenarios, you are going to want one or more Remote Access Gateways. The Remote Access Gateway serves two purposes:
The Access Point for the Users (Remote Access Client): Users, when they log into the VPN, will connect via a Remote Access Gateway. If you are using the Remote Access Client, you will need to have at least one Remote Access Gateway. You will want multiple, if you have different environments, scenarios, or simply want different access points depending on remote worker location.
A Gateway for Static WireGuard Configuration Files: The Remote Access 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.
Multiple Remote Access Gateways
You may want to consider deploying multiple Remote Access Gateways. If you want to segment traffic based on user group or use case, use multiple Gateways with different levels of access, or deployed in different networks. Example use cases:
You want remote workers to have a full tunnel VPN.
You want remote workers to have a VPN for accessing an office LAN.
You want IT admins to have remote access to edge servers.
You could have one Remote Access Gateway which has access to all these resources, or set up multiple gateways, each with access to different systems. Grant access to the appropriate gateways to the appropriate user groups.
This can be achieved in two ways:
Different Networks
Set up different networks, each with their own Remote Access Gateway, to provide access to different sets of resources. One host can act as a Remote Access Gateway in multiple networks. For instance, have a network with an Internet Gateway, a network with access to an office LAN, and a network with access to some IoT devices. The default host could act as a Remote Access Gateway in each network, providing virtual and logical segmentation between these environments. Different groups of users can be granted access to each logical gateway.
Access Controls
Set up multiple Remote Access Gateways within a single network and use Access Controls so each gateway has access to different resources. A disadvantage: a single host can only be a single gateway in the same network. Workaround: deploy multiple netclient docker containers on a physical server, each configured as a Remote Access Gateway within the same network.
Configuring the Remote Access Gateway
Setting a host as a Remote Access Gateway is simple. Go to the “Remote Access” tab of your network, and create a Remote Access Gateway from an existing Host. A few considerations:
The Remote Access Gateway must be deployed on a Linux host (or docker container).
The Remote Access 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.
The Remote Access 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 Gateways
For a typical remote access scenario, you will want one or more Egress Gateway. The Egress Gateway forwards traffic to specified IP addresses in a remote network outside of the VPN (for example, an office LAN, cloud VPC, or edge site). Multiple Egress Gateways can be configured per-network, and multiple IP ranges or addresses can be forwarded per-gateway. For example, a single host can forward traffic to a Kubernetes cluster’s Service IP CIDR as well as the Pod IP CIDR.
A more advanced use case is to use the Egress Gateway to configure site-to-site traffic. However, local devices must be configured to forward traffic via the egress gateway, so routes must be configured on the local network after the egress gateway is deployed.
Configuring Egress
Like the Remote Access Gateway, an Egress Gateway must be run on a Linux host or Docker container.
To configure: go to the Egress tab, click create, and specify the Host. Then add ranges to the new Egress Gateway. The Host 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, advertise routes on the local network, telling devices to route the VPN and remote network CIDRs via the local egress host.
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
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. After this, the egress will forward requests to the remote networks from the local devices.
Internet Gateways
An Internet Gateway is similar to an Egress Gateway but acts as a full tunnel VPN: all device traffic will be forwarded. Egress Gateways are immediately accessible by all other hosts on the network, whereas you must specify which Hosts will use Internet Gateways since often only specific devices should use it as a full tunnel VPN. An Internet Gateway can be thought of as an Egress Gateway with a range of 0.0.0.0/0 specified.
There is additional logic involved because target devices must change their “default gateway.”
Primary use case: route device traffic destined for the internet through a specific environment (for example, corporate compliance requiring internet traffic to go through a local firewall).
Deploying an Internet Gateway must be done on a Linux or Docker Host via the Internet Gateway tab. Create a gateway and specify which devices it will act as a gateway for.
A common scenario: Host A acts as a Remote Access Gateway and Host B acts as an Internet Gateway for Host A. When users access the VPN via Host A, their traffic will be routed out to the internet via Host B.
Relays
Relays act as dedicated routing points for other Hosts in the network. Relays are useful when:
NATs and corporate firewalls obstruct peer-to-peer traffic, or devices are on unreliable networks.
A particular device’s VPN traffic must route through a particular endpoint.
Any Linux or Docker host can act as a Relay. Like the Remote Access Gateway, it should be in a stable, easily accessible environment, ideally close to the target devices (e.g., if the relayed devices are in Western Europe, place the Relay in Western Europe).
If you notice connectivity issues to particular devices, try relaying them — this often increases reliability.
To deploy a Relay: go to the Relay tab, click create, then specify the relayed devices.
You can also automatically Relay devices as they are deployed by specifying a Relay in the Enrollment Key.
Access Controls
Access Controls specify what devices have access to which other devices within a network. This allows segmentation within a single network. Often it makes more sense to have different networks for segmentation, but Access Controls are useful when segmentation within a single network is desired. Examples:
Multiple Remote Access Gateways with Different Access Levels: deploy multiple Remote Access Gateways within a single network, each with access to different resources (e.g., one with access to Hosts A, B, C; another with A, D, E).
Egress to Different Environments and/or overlapping Egress Ranges: normally you cannot deploy multiple egress gateways routing to the same IP ranges. Using Access Controls, you can tie Host A to Egress A and Host B to Egress B to resolve conflicts.
Default Access Controls
Default Access Controls are set on both the Network and Host levels.
Network default ACL: set during creation and cannot be modified afterward. If set to DENY, all Hosts will DENY access by default and connections must be explicitly specified in the Access Controls tab. If set to ALLOW (the typical default), all access is allowed and you can unselect which hosts have access to each other.
Host default ACL: can be modified on the Host’s settings in the Hosts tab. Example usage: set the network’s ACL to DENY and one host’s default policy to ALLOW so new hosts only have access to that single host by default until more access is granted.
Setting Access Controls
To set access controls: go to the Access Control tab of your network, select/deselect the connections which should be allowed, and apply them. You can also bulk select rows to make hosts inaccessible or accessible to all other 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.
Last updated
Was this helpful?