Ctrlk
APIGitHubYouTubeCommunityWebsite
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Egress

secure network routing to access private and external networks

Understanding Egress

Egress enables devices in a Netmaker network to access resources outside the overlay through a designated Linux node with connectivity to the destination environment.

This can provide access to:

  • Virtual Private Clouds (VPCs)

  • Kubernetes clusters

  • Home and office networks

  • Private corporate infrastructure

  • Data centers

  • Cloud-hosted services and applications

Once configured, authorized users and devices can securely communicate with these resources without requiring direct connectivity.

Routing Methods

Netmaker supports two methods for reaching external resources.

Site

Site routing is intended for IP-based destinations and network ranges.

Common use cases include:

  • Branch offices

  • Corporate networks

  • Data centers

  • VPCs

  • Kubernetes environments

Examples:

  • 192.168.1.0/24

  • 10.0.0.0/8

  • 10.116.0.18/32

Choose this option when the destination is identified by an IP address or network subnet.

Apps (BETA)

Apps routing directs traffic using domain names rather than network ranges.

Common use cases include:

  • SaaS platforms

  • Internal web applications

  • APIs

  • Cloud services

Examples:

  • example.com

  • api.example.com

Choose this option when access is required to a specific service or application rather than an entire network.

Apps routing is currently in BETA and may change in future releases.

Network Address Translation (NAT)

In most deployments, Network Address Translation (NAT) is required unless the destination environment can directly return traffic to Netmaker clients.

Two NAT modes are available.

  • Direct: The traditional NAT mode that requires unique IP ranges for each remote site. This option is recommended when every connected environment uses different subnets and no address overlap exists.

  • Virtual: A new mode available in the enterprise plan that assigns virtual IP ranges, allowing multiple sites with overlapping local IPs to coexist. It resolves a key limitation by enabling connectivity across these overlapping networks. For example:

    • NYC Office → 192.168.1.0/24

    • LA Office → 192.168.1.0/24

    • Chicago Office → 192.168.1.0/24

    Normally, these overlapping ranges create routing conflicts. Virtual NAT solves this by assigning a unique virtual subnet to each location and automatically translating traffic between the virtual and actual addresses.

NAT can be disabled for users who prefer to manage their own masquerading and post-routing rules, or who need to preserve source IP addresses.

Feature

Direct NAT

Virtual NAT

Supports unique subnets

Yes

Yes

Supports overlapping subnets

No

Yes

Additional address translation

No

Yes

Enterprise feature

No

Yes

Recommended for

Standard deployments

Multi-site overlapping networks

High Availability

For additional resiliency, connectivity can be provided by multiple Linux nodes sts instead of a single machine.

Rather than selecting one node, administrators can assign a tag. Any node carrying that tag becomes eligible to forward traffic.

If the active host becomes unavailable, another tagged node automatically takes over, helping maintain uninterrupted access to the destination.

Access Control

Routing determines how traffic reaches a destination, while Access Control Policies determine who can use that path.

Administrators can restrict access using:

  • Nodes

  • Tags

  • Users

  • Specific IP addresses

This enables organizations to limit connectivity to only the resources that are required.

Configuring an Egress Gateway

Deploy a netclient on a network-accessible Linux node such as a server, office router, or Kubernetes worker node that is stable and mostly static (minimal IP changes or downtime). For HA Egress, you can assign the route to a group of Linux nodes to provide redundancy and continuous connectivity.

Click the Add Route button to begin creating a new Egress Route.

Step 1: Choose Routing Mode

When creating an Egress Route, first select how traffic should be routed.

Site

Routes traffic based on:

  • Subnets

  • Individual IP addresses

  • Network ranges

Use this option when connecting to private infrastructure or remote networks.

Apps (BETA)

Routes traffic based on:

  • Domains

  • Application endpoints

Use this option when providing access to SaaS platforms, APIs, or web applications.

Click Next to continue.

Step 2: Configure Route Details

1

Enter a Name (Required)

In the Name field, enter a unique and descriptive name for this egress route.

2

Enter a Description (Optional)

In the Description field, optionally describe the purpose or location of this egress route.

3

Set the NAT mode to Direct or Virtual

Direct: Standard NAT for unique IP addresses.

Virtual: Enables multiple sites with overlapping IPs.

4

Specify Egress Range or Application (Required)

Enter the external resource this egress route should reach. You can specify:

Example

  • Subnet → 10.116.0.0/20

  • Application → AWS S3 (ap-east-2) Service

5

Click "Next"

After completing all fields, click the "Next" button to continue with the egress route creation.

6

Select a node to act as an Egress

Select the node to serve as the Egress node for the route, or assign a tag to enable HA Egress.

High availability is not supported for Apps egress routes

Configure Egress Access Policies (Optional but Recommended)

Purpose: Define which nodes and users are allowed to access the egress route.

1

Add Resources Policy

Select the nodes that are allowed to route traffic through the egress route.

2

Add Users Policy

Select the users who are allowed to access the egress route

3

When finished, click "Finish" to save the configuration.

4

If you have multiple Apps/IP Ranges to add, click "Add Route" again.

Netmaker will set either iptables or nftables rules on the node depending on which one you have installed on your client. This will then implement these rules, allowing it to route traffic from the network to the specified range(s).

The Overlapping IP Problem

In many organizations, remote sites independently use the same private IP address ranges. This is very common because:

  • Branch offices often use standard ranges like 192.168.1.0/24 or 10.0.0.0/8

  • Acquired companies already have established networks that can't be easily changed

  • Customer sites use default router configurations with identical IP schemes

Why This Is a Problem: Imagine you have three branch offices:

  1. NYC office: 192.168.1.0/24

  2. LA office: 192.168.1.0/24

  3. Chicago office: 192.168.1.0/24

Each office has a server at 192.168.1.10. When you try to connect to 192.168.1.10, which office's server should you reach? Your network can't tell them apart because they all use the same address. This creates a routing conflict.

Traditional Limitation: In Direct NAT mode, Netmaker could only route to one office at a time. Accessing additional sites required renumbering networks to ensure unique IP ranges—a costly and time-consuming process.

Virtual NAT Mode: The Solution for Egress Routes

Virtual NAT mode assigns each remote network accessed through an Egress Route a unique virtual IP range. When you configure an Egress Route with Virtual NAT:

  • You specify the actual remote network in the Egress field (e.g., 192.168.1.0/24)

  • You select "Virtual" as the NAT mode

  • Virtual NAT automatically assigns a unique virtual IP range (e.g., 198.19.10.0/24) defined under the network settings

  • Netmaker clients use the virtual range to access the remote network

  • The egress node automatically translates between virtual and actual IPs

This removes the previous limitation on overlapping IP ranges for Egress Routes, enabling both site-to-site and remote access use cases with conflicting network addresses.

Setting Your Own Virtual IP Range

  1. Access the network interface and edit the network settings

  2. Enter the desired virtual subnet (e.g., 197.0.8.2/16)

  1. Apply network configuration changes.

Advanced Use Cases

  1. Segmenting Traffic Flow Through Egress Gateways

    User will need to add these additional routing rules on the egress machine to segment traffic to multiple egress ranges as desired when on multiple networks

  1. IPv6 NAT Masquerading for Egress Gateways

    Currently IPv6 Egress Gateways are not working because the default kernel builds for most common linux distributions do not support ipv6 masquerading. Custom linux kernel needs to be built with flag for enabling ipv6 masquerading to get ipv6 egress gateways working.

    Some online resources about the topic:

Egressing External Clients

Unmanaged external clients that are directly connected to a Remote Access Gateway can also act as egressing machines. The idea is the same as egress gateways. The only difference is that Netclient is necessary with egress gateways, whilst only Wireguard is needed with egressing external clients. This feature is provisioned for situations or scenarios where installation of Netclient is not ideal or even possible. For example most VPN routers support WireGuard, but they are available only as plugins that are tailormade or closely coupled with the router’s firmware or user interface. While there are ways to make Netclient work for some routers, the integration could get cumbersome, obsolete, or compromising. Of course this feature is also applicable for simple or ad-hoc networking purposes so long as the external client supports iptables and IP forwarding.

At the time of this writing, this feature only supports Linux-based external clients. But the remote machines can be anything, provided they are in the same local network as one of the egressing external client’s network interface.

Configuring Egressing External Clients

The configuration is pretty much the same as Egress Gateways. First, make sure that iptables is installed and IP forwarding is enabled. Please refer to your distro’s documentation on how to do this. For Ubuntu you might do:

You can then responsibly specify the applicable egress ranges on the external client’s VPN configuration, specifically in the “Additional Addresses” field as shown in the image below. It goes without saying that you can specify single addresses such as 172.16.1.2/32.

Your Netmaker server will then pick up the egress ranges and propagate it to all the other managed devices in the netmaker network. And of course you can edit them anytime when necessary. For more information on how to create or edit client VPN configurations, please refer to these links:

Deploying Static WireGuardIntegrating Non-native Devices

In some cases you might need to add POSTROUTING rules. In Ubuntu, you might do:

PreviousTag Management
NextDNS

Last updated

Was this helpful?