DocsAPI

Networking Scenarios, VPN Types, and Terminology

IntroductionCopied!

The purpose of this chapter is to provide you with an overview of some common networking scenarios we see at Netmaker that you may be attempting to implement, and explain some terms as they relate to these scenarios, to provide context throughout the course of the guide.

By the end of this chapter, you should have a general understanding of the various scenarios, how they relate to Netmaker, and the terminology typically employed in these scenarios.

Types of VPNsCopied!

When an administrator is tasked with setting up a VPN, they likely have a particular goal, or set of goals. Here are some of the most common we see:

  1. Provide a group of users with remote access to a site, such as an office, or to particular devices, such as a server. We call this Remote Access.

  2. Route all user or device network traffic through an endpoint (Gateway). We call this a Full Tunnel VPN.

  3. Create secure links between particular devices, such as servers at the edge, and VMs in the cloud. We call this a Point-to-Point VPN.

  4. Create secure links between sites, such as an office and a cloud environment. We call this Site-to-Site.

You may be attempting to accomplish one or more of these goals. For example, your employees may need remote access to the office, and the office may need a site-to-site connection with a data center. All can be accomplished with Netmaker, using multiple VPN networks configured in different ways, to create a mix of VPN topologies. 

Points and SitesCopied!

Before discussing these scenarios, let’s break it down into the base components: points and sites.

What is a Point?Copied!

By point, we mean an endpoint. Think of a particular device, server, or IP address. A point is one particular network resource. When we use words like device, host, node, endpoint, peer, or ip (singular), we are typically referring to a “point.” Points are typically configured with a VPN client on the device itself, so that you have direct access to (or from) the resource over the VPN.

What is a Site?Copied!

A Site is typically a local or private network, a subnet or ip cidr range. It could be an office LAN, a data center subnet, or a cloud VPC. Think of it as a collection of network resources contained within a subnet. You may need to provide access to or from these sites. When we mention  an environment, subnet, local network, private network, cidr, or vpc, we are typically referring to a “site.” 

A site is not meant to refer to the whole internet, but conceptually, you can think of the internet as just a really big site, with special rules.

Usually, access to and from sites is not direct, meaning, the VPN is not configured on all the particular points within those networks. Instead, usually, a single point will act as a gateway, and route traffic to or from the network. That point, usually a server or router, is the only device configured with the VPN inside of the network, and routes traffic to and from the other devices, which simplifies operations.

Types of VPNsCopied!

Now let’s discuss the types of networks you can create with points and sites.

Point-to-Point (Peer-to-Peer)Copied!

In a point-to-point, or peer-to-peer VPN, we are connecting endpoints directly to one another. This is useful to minimize network hops, minimize the security perimeter, and create lower level access controls between devices on the network. If you have a server in a data center that needs to connect directly to a VM in the cloud, this would be point-to-point. This is also commonly referred to as “peer-to-peer.” Another modern phrase for this is a mesh VPN. 

In Netmaker, this is the default configuration when you deploy VPN endpoints using the Netclient

.

Hub-And-SpokeCopied!

In a Hub-And-Spoke VPN, we are connecting endpoints together via a Hub. The Hub is one of the points in the network, which is forwarding traffic to and from the other points. This can simplify setup and increase reliability, though it comes at the cost of increased latency, because connections are not direct.

In Netmaker, if you use Static WireGuard to deploy endpoints, they will be using a Hub. If you choose to use a Relay for a particular endpoint, it will also use a Hub. By using the netclient, static wireguard, and/or the Relay feature in Netmaker, you can have a mix of point-to-point, and hub-and-spoke within a single network.

Point-to-SiteCopied!

In a Point-to-Site VPN, we are connecting endpoints to a full site, by routing traffic through an endpoint (or endpoints) at that site. We assume that the site itself is not a part of the VPN. As an example, if you are providing remote access to an office network from remote employee devices,, this would be point to site. Traffic would be routed into the office network via a VPN endpoint on the office network, but the destination of the traffic is outside the VPN.

We often refer to this as “Remote Access.” This is the most common form of VPN we see at Netmaker, so we’ll go into more details on this topic below.

Note the similarities between a Point-to-Site and Hub-and-Spoke network, where a single point is relaying connections to and from the site.

Site-to-SiteCopied!

In a Site-to-Site VPN, we are connecting sites together over the VPN, without installing the VPN on all the devices at the site. Typically, you have two or more office locations, and want to configure secure links between the offices (sites). So, you install the VPN on routers at these sites. The routers send traffic to each other over the VPN, and forward traffic from the VPN into the local network, returning the response to the other site.

Site-to-Site VPNs can also be created using a Hub-and-Spoke pattern, which can again simplify operations. In Netmaker this is the configuration when you use static wireguard on the routers.

Full Tunnel VPN (Internet VPN)Copied!

A Full Tunnel VPN is basically a Point-to-Site VPN, where the “Site” is the entire internet. All of the traffic from the “Points”, regardless of the destination, is routed through a particular endpoint on the VPN, and then forwarded to the internet. This is how a standard “layperson” VPN functions, for example NordVPN. In a business setting, you might want to set this up in order to monitor or restrict internet access from employee devices, by routing traffic through an endpoint where some firewall functionality is installed. In Netmaker, this is done via Internet Gateways.

Combining PatternsCopied!

At Netmaker, we find that many users are looking to accomplish more than one of these patterns simultaneously. Consider Customer X, who wanted to:

  1. Provide Remote Access to the Office from Remote Employee Workstations

  2. Route Employee Internet Traffic through an Endpoint in the Office

  3. Create a Site-to-Site Connection between the Office and their Cloud

The end result looking something like this:

The result was a mix of point-to-point, site-to-site, full tunnel, and hub-and-spoke patterns. Luckily, all of this can be done with Netmaker!

Remote AccessCopied!

Lastly, let’s discuss Remote Access in more detail, which is usually a Point-to-Site VPN, where Employee devices are the points, and offices or clouds, or edge environments are the sites.

Remote Access is the process of providing access to a site from users. 

Remote Access typically consists of a few components:

1. Source Devices, which are attempting to access the destination environment

2. A Connection Hub for incoming connections from Source Devices

3. The Destination Environment

4. A Forwarding Endpoint in the Destination Environment

Source DevicesCopied!

These are the endpoints, devices, or users making requests. These devices could be anywhere, and must run some form of VPN Client in order to access the network securely to make requests. 

Examples of source devices may include:

  • A laptop

  • A phone

  • A server

  • An IoT device

  • A router

In the context of Netmaker, we recommend the Remote Access Client for user access, which allows users to authenticate using their credentials before they can make requests. Optionally, an administrator could use manually configured WireGuard VPN clients, to create always-on VPN access. Lastly, they could use the Netclient, though this is typically meant for servers, and in order to create peer-to-peer connections.

Connection HubCopied!

This is the gateway used by the source machines to access the network. It acts as a reliable entrypoint for traffic, and checks to make sure requests are allowed and valid before forwarding them into the network. In Netmaker this is called the Remote Access Gateway, which routes traffic from both static wireguard clients, and the Remote Access Client. The Remote Access Gateway can be configured with DNS rules, which get populated to the source devices, so they can use local DNS in the destination environment.

If using the Netclient, no Hub is necessary, since connections are direct.

Destination EnvironmentCopied!

This is the site being accessed from the source devices. More specifically, this will be IP addresses at the site, typically a CIDR range or ranges (subnets), or specific endpoints (IP addresses). Example destinations may include:

  • A cloud VPC

  • An office network

  • A kubernetes cluster

  • A data center

  • A database

Additionally, there may be some private DNS configured at the site which you may want source devices to use, for example, so they can simply navigate to printer.mycompany.internal in their browser, rather than having to know the actual endpoint, which may be something like 192.168.15.35.

Forwarding EndpointCopied!

This is a point located inside the Destination Environment, which routes traffic to the local network.

 In Netmaker, this most commonly configured using an Egress Gateway, but depending on the scenario, may be done in some different ways:

  • Egress Gateway: The most common scenario is to use an Egress Gateway. You simply specify which a device running the netclient as an Egress Gateway, and select which IPs and CIDRs it should route. The settings are applied automatically to the device, and to the network, creating a split tunnel VPN for end users and devices.  

  • Internet Gateway: This is set up in the same way as an Egress Gateway, the difference being, an Internet Gateway will forward all traffic. You do not specify IPs. This creates a  full tunnel VPN.

  • VPN Config File: If access must be configured on a device which cannot run the netclient, such as a Router, you can generate a VPN Config File on your Remote Access Gateway, specify the Allowed IPs of the target environment, and run the file on the gateway device, e.g. on a Router using the WireGuard plugin. The VPN configuration can be run using any WireGuard runtime or plugin, and WireGuard can be run on most devices. The most common scenario is access to a site with a router which has the WireGuard plugin.

End Result ExamplesCopied!

Let’s quickly show some of the end results you may be looking for when you set up Remote Access.

Remote Access to a Site

Your users or devices need to access a site remotely and securely. Ex:

  • Employees need to access an office network remotely

  • Engineers need to access a data center remotely

  • Application running on-prem needs to access cloud VPC

Internet Access through a Site 

Your users or devices need to access the internet via a server at a site. Ex:

  • Employees need to access the internet through the office network

  • Customers need to access the internet through a server you manage

Remote Access from a Site

While not exactly what we described for “remote access”, you may instead wish to create an inverse scenario, where the goal is still to provide Remote Access, but from an entire site, where the VPN is not installed on all the devices. This would be more of a “Site-to-Site” or even “Site-to-Point” VPN.

Your users and devices at a site must have access to resources at a remote location. Ex:

  • Engineers need to access the data center subnet from the office network

  • Data center resources needs access to cloud services

Remote Access between Sites

Again not really considered “Remote Access” but worth exemplifying, that you may be attempting to provide access between two or more sites, without deploying VPN endpoints on all devices at each site.

This is “Site-to-Site” Networking, where two or more sites must have access to each other. Ex:

  • Multiple office branches

  • Hybrid cloud environment

  • VPC Peering

Next StepsCopied!

Now that we’ve covered the basic scenarios and patterns, let’s discuss the practical Netmaker terminology used in implementing these use cases.