OverviewCopied!

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 EndpointCopied!

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: Go ahead and 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 TopologiesCopied!

Let’s quickly review a few example patterns, and what you will likely be doing in Netmaker.

Peer-to-PeerCopied!

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, ifyou have some devices in various, scattered networks which need to communicate with each other over a /h2secure channel.

Hub-And-SpokeCopied!

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-TunnelCopied!

To create a Full-Tunnel VPN, you will set a Host as an Internet Gateway, and select which Hosts it will forward traffic for. In the instance of a Full Tunnel VPN for Users, you can create an Internet Gatway and a Remote Access Gateway, on the same or different devices, and then users can access the internet over the VPN.

Remote AccessCopied!

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-SiteCopied!

If you would like to forward traffic between two or more local networks, such as offices or data centers, this accomplished via two methods, and the configuration is very different:

1. Hosts and Egress Gateways: In this scenario, you deploy a Host in each Site, and set it as an Egress Gateway to the local network. Then, in each site, you need to configure forwarding rules, either via Router configuration or some other method, so that local devices will push traffic destined for the other sites via the local Host.

2. Remote Access Gateways and WireGuard Config Files: In this scenario, a single Remote Access Gateway can serve as the “Hub” of a Hub-and-Spoke shaped site-to-site network. For each site, a WireGuard config file will be generated, and the local IP ranges specified. This config file will then typically be applied to a router at each local site, and traffic between the sites will then begin to flow through the Remote Access Gateway and out to the other sites.

Failover ServersCopied!

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, simply click the “There's no failover host present in the network. Set one for redundancy, in case of failure.” warning message switch named as “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 which is easily reached by all hosts in the network.

Remote Access GatewaysCopied!

In most scenarios, you are going to want one or more Remote Access Gateway. 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, you can instead 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 GatewaysCopied!

You may want to consider deploying multiple remote access Gateways. If you want to segment traffic based on user group or use case, you should use multiple Gateways with different levels of access, or deployed in different networks. For example, maybe you have all 3 of the following:

1. You want remote workers to have a full tunnel VPN

2. You want remote workers to have a VPN for accessing an office LAN

3. You want IT admins to have remote access to edge servers

You could have one Remote Access Gateway, which has access to all of these resources, or you could set up multiple gateways, each with access to different systems. You can then grant access to the appropriate gateways, to the appropriate user groups.

 This could be achieved in two ways:

Different Networks

You can set up different networks, each with their own Remote Access Gateway, to provide access to the different sets of resources. An advantage of this method is that one host can act as a Remote Access Gateway in multiple networks. For instance, you can set up a network with an Internet Gateway, a network with access to an office LAN, and a network with access to some IoT devices. You could have the default host acting as a Remote Access Gateway in each network. It provides virtual and logical segmentation between these environments, and different groups of users can be granted access to each logical gateway.

Access Controls

You can also set up multiple Remote Access Gateways within a single network, and use Access Controls so that each gateway has access to different resources. A disadvantage of this approach is that a single host can only be a single gateway in the same network. However, as a workaround you can deploy multiple netclient docker containers on a physical server, each configured as a Remote Access Gateway within the same network.

Configuring the Remote Access GatewayCopied!

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:

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

2. The Remote Access Gateway should be accessible by all remote devices which will use it, typically meaning it is in a public environment, like the cloud, or with appropriate routing set up for the IP and Port of the netclient.

3. The Remote Access Gateway should be stable, meaning it should ideally have a dedicated, static IP address (not floating), Port, no NAT restrictions, and not be 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 GatewaysCopied!

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 instance, an office LAN, a cloud VPC, or an edge site. Multiple Egress Gateways can be configured per-network, and multiple IP ranges or addresses can be forwarded per-gateway. For example, you can have a single host 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. For instance, allowing a LAN to access the VPN. However, the local devices must be configured to forward traffic via the egress gateway, and so routes must be configured on the local network after the egress gateway is deployed. 

Configuring EgressCopied!

Like the Remote Access Gateway, an Egress Gateway must be run on a Linux host or Docker container.

It is similarly easy to configure. Just 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 EgressCopied!

Egress makes local networks accessible from the VPN. But what if you want the local networks to be able to reach the VPN, or each other? Consider the following networks:

Netmaker VPN: 100.10.10.0/24

Cloud VPC of 172.98.52.0/24

• Netclient with Egress deployed

Office LAN of 192.20.0.0/16

• Netclient with Egress deployed on 192.20.10.15

How would you make the LAN able to reach the Cloud VPC and Netmaker VPN?

In this scenario, Routes should be advertised to the network, telling devices to 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 GatewaysCopied!

An Internet Gateway is similar to an Egress Gateway, but acts as a full tunnel VPN, meaning all device traffic will be forwarded. Additionally, Egress Gateways are immediately accessible by all other hosts on the network, whereas you must specify which Hosts will use Internet Gateways, since it is often the case that only specific devices should use it as a full tunnel VPN. You can think of an Internet Gateway as an Egress Gateway with a range of 0.0.0.0/0 specified. 

However, there is some additional logic involved, since target devices must change their “default gateway.”

A primary use case for the Internet Gateway is to act as a routing point for device traffic destined for the internet. This might be because of corporate compliance, which specifies internet traffic must go through the local firewall, or other such restrictions. Typically, there is some environment, through which internet traffic must go, for one reason or another.

Deploying an Internet Gateway, similar to Egress and Remote Access, must be done on a Linux or Docker Host, and can be done via the Internet Gateway tab. Simply click to create a gateway, and specify which devices it will act as a gateway for.

A common scenario is to deploy one Host (Host A) which acts as a Remote Access Gateway, and another Host (Host B) which acts as an Internet Gateway for Host A. Then, when users access the VPN via the Remote Access Gateway (Host A), their traffic will be routed out to the internet via Host B.

RelaysCopied!

Relays act as dedicated routing points for other Hosts in the network. Relays are a useful feature for a two scenarios:

1. When NATs and corporate firewalls get in the way, or devices are on unreliable networks. 

2. When a particular device’s VPN traffic must route through a particular endpoint

Again, any Linux or Docker host can act as a Relay, and like the Remote Access Gateway, it should be in a stable, easily accessible environment, ideally close to the target devices (if the relayed devices are in Western Europe, try to have a Relay in Western Europe).

If you are noticing connectivity issues to any particular devices, try relaying them, as this often increases the reliability of the connection.

To deploy a Relay, simply go to the Relay tab, click create, and then specify the Relayed devices.

As noted in the Deploying Hosts section, you can also automatically Relay devices as they are deployed, by specifying a Relay in the Enrollment Key.

Access ControlsCopied!

Access Controls specify what devices have access to what other devices within a network. This is a simple mechanism that allows you to segment access within your network. Often, it makes more sense to have different networks, which are automatically segmented and can be used for different use cases. However, sometimes, you may wish to manage this within a single network, in which case, access controls can be used. Here are two examples of why you might want to use Access Controls.

Multiple Remote Access Gateways with Different Access Levels

You can deploy multiple Remote Access Gateways within a single network, which have access to different resources within that network. One could have access to Hosts A, B, and C, while another has access to A, D, and E.

Egress to Different Environments and/or overlapping Egress Ranges

Typically, you cannot deploy multiple egress gateways within a single network which route to the same IP ranges. If you do this, the netclient will not know which one to send it to! However, if you use access controls, you can specify that Host A is connected to Egress A, and Host B is connected to Egress B, which resolves the issue.

Default Access ControlsCopied!

Default Access Controls are set on both the Network and Host level. When creating a network, the default ACL can be set to DENY, meaning all Hosts will DENY access by default. Connections must be manually specified in the Access Controls tab. If set to ALLOW (which is what we usually do) All access is allowed by default, and you can unselect which hosts have access to each other in the ACL tab.

On the host level, you can also set a default DENY or ALLOW policy. This can be useful if, for example, you are creating a network where only one machine should be accessible by default. To do this, you would set the network’s ACL policy to DENY, and set the accessible host’s default policy to ALLOW. Then, as hosts join the network, they will only have access to this single host by default, unless otherwise granted.

The network’s default ACL must be set during creation and cannot be modified. To modify a Host’s default ACL, go to the Host’s settings in the Hosts tab of your network, edit, and modify the ACL policy.

Setting Access ControlsCopied!

To set access controls, simply go to the Access Control tab of your network. You will select and de-select the connections which should be allowed, and then apply them. You can also bulk select on rows, to make hosts inaccessible or accessible to all other devices.

Next StepsCopied!

In the next section, we’ll discuss the 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.