> 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/acls-access-controls.md). # ACLs - Access Controls Easily manage network access with the new Netmaker ACLs {% embed url="" %} 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](https://docs.netmaker.io/docs/features/tag-management-pro) 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.

--- # 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/acls-access-controls.md?ask=&goal= ``` `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.