Today, we're announcing Netmaker v0.22.0. Don't let the small version increment fool you, because this comes with some big changes. This release has been two months in the making, and has two core focuses:

1. Network Stability
2. Aligning with our network design pattern

Before hopping into the updates, lets briefly discuss the network design pattern, or, how Netmaker is approaching a typical network setup.

The Network Design Pattern

A network typically consists of devices which are either controlled by users (laptops, phones) or not (servers, IoT devices). Netmaker is drawing a clean distinction between the two device types.

Non-User Devices

Examples: IoT devices, servers, VM's

Considerations: These devices typically need peer-to-peer access to one another, or need to act as gateways to, from, or between devices. They need to be controlled remotely, so should have an always-on VPN agent.

Netmaker Integration: Use the Netclient where possible. For unsupported devices, use the Client Gateway + Client Config files, utilizing any standard WireGuard application.

User Devices

Examples: Laptop, Phone

Considerations: These devices typically need to be authenticated via IDP, as the user who is operating them. These users typically want a GUI to manage their VPN connection. Users typically need to access services running on the non-user devices.

Netmaker Integration: Use the Remote Access Client + Client Gateway for these devices if using Netmaker Pro. If using Community (OSS), use the Client Gateway + Client Config files, utilizing any standard WireGuard application.

Now that we've discussed this pattern, let's go through the updates in v0.22.0:

DNS moving to CoreDNS Only

We're deprecating our /etc/hosts management implementation on the Netclient. Going forward, you will need to manually add DNS resolution to hosts if you would like to include this management. We're changing this because the primary use case for DNS is for end users. End users will continue to have DNS resolution via CoreDNS, using the remote access gateway. For servers, administrators should be comfortable modifying DNS settings to use a private endpoint.

Internet Gateway Redesign

Moving forward, the internet gateway will only function via the remote access gateway. The reason being, similar to above, is that most use cases require this only for end users, not devices, and the internet gateway causes many complications for peer-to-peer networks. This is a much more stable design, and allows administrators to easily create the standard "internet VPN" pattern for their users (think NordVPN, ProtonVPN, ExpressVPN).

MQ Fallback

Ever notice your hosts in "Error" status in the UI? This happens when the MQ connection fails. This is how Netmaker communicates with machines in your network. When this communication fails, there can be major disruptions in your network, since machines will not get updates about changes to other machines in the network, such as IP, port, keys, etc.

With MQ Fallback, the netclient can now automatically "pull" and "push" changes over the API, rather than MQ. This failsafe will keep your network functioning and up-to-date, even when MQ fails.

TURN -> Failover Servers

When peer-to-peer connections fail, we used TURN to relay those connections. However, the TURN implementation hasn't lived up to our standards. Instead, we're moving to a WireGuard-native approach we're calling failover servers. This is a pro-only feature, and enables you to designate servers which will act as fallback for peer-to-peer connections.

Get Started

For the full breakdown of updates, and to try it out, check out the release on GitHub: https://github.com/gravitl/netmaker/releases/tag/v0.22.0

‍