# Egress {% embed url="" %} ## Understanding Egress Netmaker's Egress feature allows your network clients to reach external networks through a designated linux node. An Egress node is a netclient deployed on a device or router that has access to a specific subnet, such as: * A Virtual Private Cloud (VPC) * A Kubernetes Network * A Home or Office Network * A Private Network * A Data Center
When you create an Egress Route in the Netmaker UI, you specify which external network ranges the egress node can reach. Once configured, all clients in your Netmaker network (including external clients) can access those ranges through the Egress node.
Network Address Translation (NAT) is typically required for Egress nodes unless the external network can directly route traffic back to the Netmaker nodes. Netmaker now offers two NAT modes when configuring Egress Routes: Direct and Virtual When creating an Egress Route with NAT enabled, Netmaker offers two NAT modes:
* **Direct:** The traditional NAT mode that requires unique IP ranges for each remote site * **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. {% 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 %} ## 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 open the "Create New Egress Route" modal.
{% stepper %} {% step %} ### Enter a Name (Required) In the **Name** field, enter a unique and descriptive name for this egress route. Example: `nyc-office` {% endstep %} {% step %} ### Enter a Description (Optional) In the **Description** field, optionally describe the purpose or location of this egress route. Example: `NYC office LAN network` {% endstep %} {% step %} ### Set the NAT mode to Direct or Virtual (Required) **Direct:** Standard NAT for unique IP addresses. **Virtual:** Enables multiple sites with overlapping IPs. {% endstep %} {% step %} ### Specify Egress Target (Required) In the **Egress** field, enter the external resource this egress route should reach. You can specify: * Subnet → `10.116.0.0/20` * Single IP → `10.116.0.18/32` * Domain (BETA) → `example.com` {% 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 (netclient) to serve as the Egress node for the route, or assign a tag to enable HA Egress.
{% endstep %} {% endstepper %} ### Configure Egress Access Policies (Optional but Recommended) Purpose: Define **which nodes and users** are allowed to access the egress route.
{% stepper %} {% step %} ### Add Resources Policy Select the **nodes** that are allowed to route traffic through the egress route.
{% endstep %} {% step %} ### Add Users Policy Select the **users** who are allowed to access the egress route
{% endstep %} {% step %} ### When finished, click "Finish" to save the configuration.
{% endstep %} {% step %} ### If you have multiple 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\
* 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`)\
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 ``` plaintext 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 ``` plaintext ### 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: ```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.
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="../getting-started/operations-field-guide/deploying-static-wireguard" %} [deploying-static-wireguard](https://learn.netmaker.io/getting-started/operations-field-guide/deploying-static-wireguard) {% endcontent-ref %} {% content-ref url="../how-to-guides/integrating-non-native-devices" %} [integrating-non-native-devices](https://learn.netmaker.io/how-to-guides/integrating-non-native-devices) {% 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: 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: ``` GET https://learn.netmaker.io/features/egress.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.