ACLs - Access Controls

Easily manage network access with the new Netmaker ACLs

With the latest ACL feature in Netmaker, managing network access has never been easier. This powerful addition allows network administrators to control communication between devices by defining policies that restrict or allow access.

What is an ACL?

An Access Control List (ACL) is a set of rules that specify which users or devices are allowed or denied communication within a network. ACLs are used by network administrators to control traffic flow, ensuring that only authorized entities can access or interact with certain network resources, enhancing overall network security.

There are two main types of ACL policies: User Policies and Resource Policies

User Policies

This type of policy controls which users can access or interact with specific network devices (e.g., servers, databases, gateways). It ensures that only authorized users have permission to access sensitive devices or services.

Example: Grant access to a DevOps team for database servers while restricting other teams' access to the same resources. This ensures only authorized users can access sensitive resources, improving network security.

Resource Policies

This policy controls which devices (like servers, web applications, databases, or gateways) can communicate with each other. It restricts or permits communication between devices based on the network's security needs.

Example: A web server might be allowed to communicate with a database server but blocked from connecting to other devices, such as file storage servers or printers. This limits unnecessary or unauthorized traffic between devices, enhancing network security and performance.

Default Policies

The Default Policies are automatically generated whenever a new network is created, enabling unrestricted two-way communication between users and resources, as well as between resources themselves. These policies ensure full connectivity during the initial setup.

1. All Nodes: Enables all resources (e.g., servers, gateways) to communicate freely with one another in both directions.
2. All Remote Access Gateways: Allows remote access gateways (remote-access-gws) to communicate with all resources and vice versa.
3. All Users: Grants all users full access to all resources, ensuring open two-way communication.
4. Network Admin: Grants users in the netmaker Admin Group and the All Networks Admin Group full two-way communication with the remote access gateways (remote-access-gws) and associated resources.
5. Network User: Grants users in the netmaker User Group and the All Networks User Group unrestricted access to remote access gateways (remote-access-gws) and associated resources in both directions.

How to Add ACLs in Netmaker

Navigate to the Access Control page to view a list of all ACLs across the network. From there, you can enable or disable any ACL as needed. To create a new policy, simply click Add Policy.

Here, you can define a custom rule by specifying:

• Policy For: Choose whether the policy applies to resources (controlling device access) or users (managing user permissions).
• Rule Name: Give the rule a clear name, like "api-gateway-access" or “devops-team”
• Source and Destination: Select the source and destination entities to control which nodes can communicate. Tags are available to help group nodes and apply rules more efficiently.
• Enable Policy: Toggle this switch to activate or deactivate the policy.

Once configured, click Save Policy to apply the policy.

To enable communication between peers in the same group, add the group to both the Source and Destination fields.

How to Update ACLs in Netmaker

Identify the ACL policy you want to update, click on the three dots, and choose the "Edit" option

After selecting "Edit," make the necessary adjustments to the ACL policy settings based on your requirements.

How to Remove ACLs in Netmaker

Identify the ACL policy you want to remove, click on the three dots, and select the "Remove" option.

Advanced ACL Capabilities

Egress ACLs with IP Restriction

Netmaker’s Egress feature allows traffic to be forwarded from the mesh network to external networks such as office LANs, data centers, or legacy infrastructure. With the latest ACL enhancements, access control can now be applied at the IP level inside an egress CIDR range.

This provides fine-grained control over external network access without exposing entire subnets.

Key capabilities:

• Restrict access to specific IPs inside a larger egress CIDR block.
• Apply ACL rules to individual endpoints within external networks.
• Combine egress resources, nodes, tags, and IP-level targets in a single policy.
• Define one-way or two-way traffic rules depending on the use case (e.g., mesh network nodes can reach egress network IP(s), or egress network IP(s) can reach mesh network nodes)

Example: Allow access only to 192.168.10.25 (a specific internal service) within an egress network, while blocking all other IPs in the same subnet.

Where to configure Egress ACLs

Egress-related ACL policies can be created and managed in two places depending on your workflow:

From the Egress screen

Use this when configuring or editing an egress resource. ACL rules can be defined directly in context to immediately control traffic flowing through that egress.

From the Access Control screen

Use this when you want to centrally manage all ACL policies, including those targeting egress resources, IPs, or external networks.

Example: You define a global ACL policy that allows only the prod-services tag to access 10.20.5.10 through any egress resource, while denying all other tags from reaching that IP.

Access control rules can be configured as one-way traffic or two-way traffic, depending on the required access model.

In the following one-way setup, only mesh network nodes are allowed to initiate connections to the egress network IP (10.20.5.10), for services like accessing external resources or APIs.

And In the following two-way setup, you can allow the egress network IP (10.20.5.10) to initiate connections back to mesh network nodes for services like monitoring or database callbacks.

Site-to-Site ACLs (Beta)

Using Netmaker's Egress feature at different locations, entire networks can be connected together in a site-to-site setup. Site-to-Site ACLs extend Netmaker's Access Control functionality by allowing administrators to define exactly which traffic is permitted between connected sites.

Where to Configure Site-to-Site ACLs

Site-to-Site ACLs can be created from the Access Control screen by creating a Resource Policy. When defining the policy, select the source and destination resources that should be allowed to communicate.

For site-to-site deployments, it is common to use egress resources as the source and destination, then apply additional restrictions using tags, nodes, routes, or specific IP addresses to limit access to only the required resources.

Key capabilities:

• Create Access Control rules between egress resources on different networks.
• Use egress resources, nodes, tags, and IP addresses in the same rule.
• Control traffic between specific sites or IP addresses instead of full network access.
• Configure one-way or two-way communication between sites.

Traffic Direction

Access Control rules can be configured as one-way or two-way traffic.

In a one-way setup, only the source is allowed to initiate connections to the destination. Traffic initiated in the opposite direction is blocked.

Example: Allow users in the Headquarters network to access a database server located in a Branch Office network, while preventing any devices in the Branch Office network from initiating connections back to Headquarters.

In a two-way setup, both the source and destination are allowed to initiate connections to each other.

Example: Allow a monitoring server in Site A to access application servers in Site B and allow those application servers to send logs, alerts, or metrics back to the monitoring server.

IP Restrictions

When creating a Resource Access Control policy for site-to-site communication, you define the source and destination sites, and optionally restrict traffic down to specific IPs on both sides.

This allows restricting communication between connected sites at the IP level, instead of allowing full subnet-to-subnet access.

Example: A Branch Office egress advertises the subnet 10.110.20.0/24. Instead of allowing full access to the subnet from the remote site, an Access Control rule can be created to allow communication only with 10.110.20.10. All other IPs in the subnet remain inaccessible from the remote site.

For even more granular control, an Access Control rule can restrict traffic between specific IPs on both sides. For example, allow only 192.168.1.10 in Site A to communicate with 10.110.20.10 and 10.110.20.12 in Site B, while blocking all other traffic between the two sites.