> For the complete documentation index, see [llms.txt](https://learn.netmaker.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.netmaker.io/features/egress.md).

# Egress

{% embed url="<https://www.youtube.com/watch?v=4x20rkr-8jQ>" %}

## Understanding Egress&#x20;

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.

<figure><img src="/files/itG2xkYYAj73zd8UWKxb" alt=""><figcaption></figcaption></figure>

#### 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.

<figure><img src="/files/c9aZE6uLRQ6AgXboO3Qc" alt=""><figcaption></figcaption></figure>

#### 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.

<figure><img src="/files/MZkx3XFPuumqTnvtsdWo" alt=""><figcaption></figcaption></figure>

* **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 e**nterprise 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.

{% hint style="info" %}
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.
{% endhint %}

| 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.

<figure><img src="/files/Xsr7kXYVk7RWUr6EKQc6" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/itG2xkYYAj73zd8UWKxb" alt=""><figcaption></figcaption></figure>

### Step 1: Choose Routing Mode

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

<figure><img src="/files/lfO7LE910j1H6ATip8Ii" alt=""><figcaption></figcaption></figure>

#### **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

{% stepper %}
{% step %}

### Enter a Name (Required)

In the **Name** field, enter a unique and descriptive name for this egress route.
{% endstep %}

{% step %}

### Enter a Description (Optional)

In the **Description** field, optionally describe the purpose or location of this egress route.
{% endstep %}

{% step %}

### Set the NAT mode to Direct or Virtual&#x20;

**Direct:** Standard NAT for unique IP addresses.

**Virtual:** Enables multiple sites with overlapping IPs.
{% endstep %}

{% step %}

### 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`\ <br>

  <figure><img src="/files/HR7WCCSwcLHfHVHER7uf" alt=""><figcaption></figcaption></figure>

* Application → AWS S3 (ap-east-2) Service\ <br>

  <figure><img src="/files/uZxFesOtfyNyqczmYivE" alt=""><figcaption></figcaption></figure>

{% endstep %}

{% step %}

### Click "Next"

After completing all fields, click the **"Next"** button to continue with the egress route creation.
{% endstep %}

{% step %}

### 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.&#x20;

<figure><img src="/files/Qv9K8wsgQg4x7n6sLW7c" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**High availability is not supported for Apps egress routes**
{% endhint %}
{% endstep %}
{% endstepper %}

### Configure Egress Access Policies (Optional but Recommended)

Purpose: Define **which nodes and users** are allowed to access the egress route.<br>

<figure><img src="/files/lMkFwhVjfxqzIYLTRdi2" alt=""><figcaption></figcaption></figure>

{% stepper %}
{% step %}

### Add Resources Policy

Select the **nodes** that are allowed to route traffic through the egress route.<br>

<figure><img src="/files/lujVUzZgTptGNLqQhO24" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### Add Users Policy

Select the **users** who are allowed to access the egress route<br>

<figure><img src="/files/joxIaEyPmkORgSGxjG0k" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

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

<figure><img src="/files/nJRHIlMK5oGmW7q1hRQD" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}

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

{% endstep %}
{% endstepper %}

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\ <br>

  <figure><img src="/files/U5JaW5yjvDFslliUb3PX" alt=""><figcaption></figcaption></figure>
* Virtual NAT automatically assigns a unique virtual IP range (e.g., 198.19.10.0/24) defined under the network settings\ <br>

  <figure><img src="/files/06y4FPp3JGwBXVH3Oa4n" alt=""><figcaption></figcaption></figure>
* 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<br>

   <figure><img src="/files/0CWOiovnb0Tc6KSAbs6v" alt=""><figcaption></figcaption></figure>

2. Enter the desired virtual subnet (e.g., `197.0.8.2/16`)\ <br>

   <figure><img src="/files/YCj42TbzBLuehzJvrT0g" alt=""><figcaption></figcaption></figure>

3. 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

```plaintext
iptables -t filter -N netmakeregressiptables -t filter -I FORWARD -i netmaker -d egressGwRangeA,egressGwRangeB -j netmakeregressiptables -t filter -I netmakeregress -s networkRangeA -d egressRangeA -j ACCEPTiptables -t filter -I netmakeregress -s networkRangeB -d egressRangeB -j ACCEPTiptables -t filter -A netmakeregress -j DROP# NAT Rulesiptables -t nat -I POSTROUTING -s networkRangeA -d egressGwRangeA -j MASQUERADEiptables -t nat -I POSTROUTING -s egressGwRangeA -d networkRangeA -j MASQUERADEiptables -t nat -I POSTROUTING -s networkRangeB -d egressGwRangeB -j MASQUERADEiptables -t nat -I POSTROUTING -s egressGwRangeB -d networkRangeB  -j MASQUERADE
```

2. 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:

```plaintext
https://superuser.com/questions/1751062/ipv6-masquerading-on-linuxhttps://www.kernelconfig.io/config_nf_nat_masquerade_ipv6?q=&kernelversion=5.15.116&arch=x86https://www.reddit.com/r/PFSENSE/comments/vb4r3s/ip6_masquerading
```

### Egressing External Clients <a href="#egressing-external-clients" id="egressing-external-clients"></a>

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 <a href="#egressing-external-clients__configuring-egressing-external-clients" id="egressing-external-clients__configuring-egressing-external-clients"></a>

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:

```plaintext
#update
apt-get update

#install
iptablesapt-get install iptables

#enable IP forwarding
sysctl -w net.ipv4.ip_forward=1
```

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.

<figure><img src="/files/D94eOcAurKxed1ksWIDW" alt=""><figcaption></figcaption></figure>

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:

{% content-ref url="/pages/2cPkos93a9XpW2rIAmW1" %}
[Deploying Static WireGuard](/getting-started/operations-field-guide/deploying-static-wireguard.md)
{% endcontent-ref %}

{% content-ref url="/pages/5a7da52f38313d16adc5c6c16a8a2f2ec328e46c" %}
[Integrating Non-native Devices](/how-to-guides/integrating-non-native-devices.md)
{% endcontent-ref %}

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

```plaintext
#get the name of the specific network interface of the egressing client machine# that is associated with the egress ranges that you have specifiedip a#add the necessary POSTROUTING rule, say the interface name is `eth1`iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learn.netmaker.io/features/egress.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.