For many modern companies, compute resources at the edge, in the data center, or on the cloud must be reachable remotely for a variety of reasons:

• ITSP’s and MSP’s often need access to customer networks
• IT administrators often manage devices at the edge
• Developers often need access to secured compute resources
• Edge devices often need to be bridged with cloud services

Netmaker’s Egress functionality provides secure access to these remote resources, acting as the high-performance bridge to external and local networks.

Understanding Netmaker Egress

A Netmaker Egress Gateway is a device running the Netmaker agent that is set to forward traffic to an external network. This might be a server in a factory, a router in the office, or a VM in the cloud. By deploying a single agent at a site, administrators can provide access to entire local area networks (LANs), data centers, or cloud VPCs.

Effectively, the Egress Gateway acts as a traffic forwarder, taking encrypted packets from Netmaker clients (users and devices) and routing them to remote network infrastructure. This enables remote users and cloud services to interact with on-premise resources without requiring a Netmaker agent on every single device in the target network.

Key Enhancements to Egress Capabilities

Recent updates to the Netmaker platform have significantly matured the Egress function, focusing on reliability, scalability, security, performance, and ease of use.

Highly Available Egress + Latency-Aware Routing

Introduced in version 1.2.0, Egress supports full High Availability (HA) with latency-optimized pathways.

• Automatic Failover: If a primary egress gateway goes offline, the system automatically redirects traffic through the next fastest available device.
• Latency-Aware Selection: Netmaker calculates real-time latency for all available gateways and dynamically connects clients to the best-performing route.
• Business Continuity: This ensures that production connectivity remains uninterrupted and optimized in the event of failures.

Virtual NAT for Overlapping Subnets

Managing multiple sites that utilize identical IP space (e.g., several Kubernetes clusters or data center VLANs all using 10.0.0.0/24) historically creates routing conflicts. If multiple destinations share the same IP range, source traffic won’t know where to go. Netmaker solves this with its Virtual NAT mode for Egress routes.

Virtual Range Mapping: Virtual NAT mode assigned a unique virtual address range to a target destination range. For example virtual ranges of 10.10.0.0/24 and 10.11.0.0/24 can be mapped to two different 10.0.0.0/24 networks, eliminating the conflict without requiring a complete re-architecture of the existing network IP space.

The Egress Applications Catalogue

Administrators may want to route access to cloud services via Egress, to ensure that network access is properly secured. However, there are many possible destinations for cloud services, and the associated endpoints are updated on a regular basis. Maintaining access creates a significant administrative burden.

Released in  v1.6.0, the Applications Catalogue simplifies providing secure access to popular cloud and SaaS ecosystems.Administrators can instantly create egress resources for services like AWS, Google Cloud, Microsoft 365, Salesforce, GitHub, and major AI providers. Netmaker automatically resolves and maintains these application domains behind the scenes, ensuring that routing policies stay up-to-date as external service IPs evolve.

Advanced Access Controls for Egress

Netmaker aligns with the Zero Trust framework by enforcing policies over who and what can access specific resources. This is achieved through a robust Access Control List (ACL) model.

In regards to Egress routes, Netmaker allows administrators to define policies that grant or deny access to specific external routes, as well as what ports and protocols are allowed. For example, access to an office or data center network may be limited to specific user groups.

However, to go fully Zero Trust, further policy enforcement is required.

IP Restriction and Micro-Segmentation

Standard egress route policies will grant access to an entire subnet, which is often too broad for certain security requirements. A user may require access only to a specific server on a LAN, and should not be permitted to reach other resources.

Granular Targets: As of v1.6.0, ACLs can now target individual IPs within a larger egress range. This reduces the potential attack surface by restricting access to singlular resources, such as a specific database server within a data center. This effectively prevents the possibility of lateral movement within the remote subnet by malicious actors.

Site-to-Site ACLs

Netmaker’s Egress functionality can be utilized to enable full site-to-site connectivity. Rather than providing remote access to a single site, entire sites can be bridged, creating a unified environment.

However, this opens up significant security concerns. Perhaps all data center resources should be reachable from the office network, but only certain resources within the office should be reachable from the data center.

Site-to-Site ACLs alleviate this concern by allowing administrators to restrict access from remote network resources. Administrators can define policies for traffic originating from one local site and destined for another. This enables the establishment of complex multi-site architectures with security enforced via a central policy management engine.

Conclusion

By evolving beyond simple connectivity, Netmaker’s Egress functionality provides a secure, high-performance bridge tailored for modern, remote-first infrastructure. Through recent enhancements like high availability, Virtual NAT, and the Applications Catalogue, administrators can manage complex, overlapping network environments with ease.

Combined with robust ACLs that enforce granular IP restrictions and site-to-site controls, Netmaker empowers teams to implement a true Zero Trust model, ensuring that as organizations scale, their security and network reliability grow alongside them.

‍