Access Control List
Last updated
Was this helpful?
Last updated
Was this helpful?
The ACL (Access Control List) functionality in Defguard allows administrators to define and manage who can access specific network resources. It provides a clear and centralized way to control access based on users, groups, or devices, ensuring that only authorized entities can reach sensitive systems or services.
Access Control is an . To use it you'll need to or ensure your deployment does not .
Access Control is available in Defguard version ≥ 1.3.0 and Gateway version ≥ 1.3.0
Access Control is enabled / disabled for each location individually. To enable it, go to location settings (you'll find the button on the page).
There are two relevant options in the "Location configuration" section:
Select the checkbox to enable ACL for the location.
You should also set the default ACL policy for the location.
Default policy defines what happens with traffic to resources that were not explicitly specified in your ACL rules:
Allow - users / devices connected to the location will be able to access all resources within the network if the resource access is not modified by one of your ACL rules.
Deny - all traffic to network resources that is not regulated by one of the ACL rules will be dropped
Access Control List view displays all the rules defined in your system. The list is split into two sections.
"Deployed Rules" section displays the rules that were already applied. Those rules should be in effect on relevant locations if the gateway-core connection is intact.
Defguard does not track rule application status per location. In the event of network connectivity issues between gateway and core components, rule propagation is not immediate. The system guarantees eventual consistency - rules will be applied once the connection is restored.
"Pending Changes" section displays all the rules that have not yet been applied to locations. This includes:
new rules
modified rules
deleted rules
Defguard’s ACL functionality is designed to allow users to apply access control rules in batches. This approach minimizes the risk of transient network issues that could occur when deploying rules individually. By grouping changes and deploying them together, the system reduces the likelihood of connectivity hiccups or firewall disruptions.
The ACL list view also allows rule filtering by name, locations and other attributes
The ACL form consists of three main sections:
rule name
locations where the rule should be applied
enabling / disabling of the rule
This section is meant to define the resource to which access should be granted or restricted. Think of this section as the "destination" part of a firewall rule.
IP addresses (IPv4 or IPv6) of the resources for which access will be granted or restricted. The addresses can be specified individually, by CIDR addresses (with a mask) or as a range. You can specify multiple comma-separated addresses. Examples of valid values for this field include:
10.1.1.10, 10.1.2.0/24
10.2.1.10-10.2.2.100, fd00:1000::/64, fd00:1000::f0
etc.
Ports - TCP/UDP ports and port ranges
Protocols that will be affected by the rule. All by default. Defguard ACL currently supports TCP, UDP and ICMP protocols.
This section lets you define which traffic sources should be granted or denied access - essentially the "source" side of a firewall rule.
In Defguard, sources can be defined as one of three object types:
Users
User Groups
Network Devices
Each ACL rule in Defguard is intended to fully define access to a specific resource, you must therefore always include at least one allowed source.
If you give a user access to some resource through an ACL rule, but they do not have access to a given location, they still won't be able to access it, because they'll be unable to establish a VPN connection with the gateway.
Access Control List (ACL) rules in Defguard are used to manage who can access specific resources across your network. Think of each rule as a clear instruction that says: “These users or devices are allowed to reach this resource - and optionally, these others are not.”
Each rule connects who (users, groups, or devices) to what (a resource address).
At least one "allowed" source must always be specified - this defines who gets access.
Optionally, you can exclude specific users, groups, or devices using the "denied" section.
You can use this combination to create flexible rules, such as: Allow everyone in the “Remote Workers” group except a few individuals access to specific office network.
This setup helps you control access clearly and safely without worrying about lower-level network and firewall behavior.
ACL rules are self-contained - they fully define access for their target resource, are interpreted identically across all gateways and are unaffected by the "default policy" location setting.
Default policy setting at a location level does not affect traffic covered by ACL rules. It applies only to traffic targeting addresses not matched by any ACL rule.
A destination address is required in each rule - specifying only ports and/or protocols is not allowed.
Ports and protocols are optional. If specified, traffic is allowed only on those ports/protocols—everything else will be blocked.
Each ACL results in two firewall rules:
An ALLOW rule for the allowed sources.
A DENY rule to block all other traffic to that destination.
In this scenario we will allow specific users to access the 10.1.1.0/24 network if they are connecting via the "office-berlin" location.
Do do this you will add new rule with:
office-berlin location selected in the "Locations" input
"10.1.1.0/24" CIDR in the destination input
Appropriate users in the "Allowed Users/Groups/Devices->Users" input
Under the hood
You just deployed the rule to gateway. This means that the firewall on the gateway that handles the "office-berlin" location should contain appropriate nftables rules that implement the requirements you specified. Let's see what this looks like in practice. Below is the nftables list ruleset output:
As you can see, Defguard has created a new inet-type table. This is to make sure Defguard's configuration won't interfere with your existing nftables.
The FORWARD chain specifies our rules. First you can see the policy drop default, which is a result of setting the "default Deny" policy in the location settings. Then the established,related line to skip reevaluation of established connections.
Finally the two lines that directly deal with our requirement to allow the two users into the network.
This rule specifies two addresses as the "traffic source" - 10.100.200.155 and 10.100.200.156 . Those happen to be device addresses of our two users in the Wireguard VPN network that the gateway manages for this Location. The destination address "10.1.1.0/24" is exactly the network address we specified in the rule. And finally the "accept" verdict. All together, this rule allows the traffic specified in the UI to the network.
You may also notice that Defguard added a comment to the rule. The comment includes rule name so that it is easy for you to find the rule using tools like grep etc.
Finally, the last line:
This line effectively blocks all other traffic to the 10.1.1.0/24 network. As mentioned earlier, the ACL rules in Defguard are self-contained and fully define access for their target resource. This set of rules can now be deployed to any gateway, no regardless of the "default policy" setting, and they will effectively do the same thing.
Let's build on the last example. The example defined a single rule that grants access to a network to two users. In this example we will block access for one specific user. But first let's rethink our approach.
You may be tempted to specify the access for each user individually like we did while constructing the first rule. This may work at first or if your users don't change too often. But what if you have a constant influx of new users? This might get tedious pretty fast.
So what we will do is:
we will define two groups
staff-berlin
externals
we will add all the users that work in our "Berlin" office to staff-berlin group
we will add all users we collaborate with in Berlin, but are not our direct employees, to the "externals" group
we will allow all users in staff-berlin group access to the network
we will add an exception for the users in "externals" group so that they are not allowed to access the network
Once you have created appropriate groups and assigned the users, let's update the ACL rule. The rule should now:
still be assigned to the "office-berlin" location
still define the destination resource address as "10.1.1.0/24"
instead of specific users in the "Allowed Users" input we now select the "staff-berlin" group in the "Allowed Groups" input
in "Denied Groups" input we should now select the "externals" group
For traffic to flow between your network interfaces on Linux you may also need to enable IP forwarding, if you haven't done it already. This can be achieved by setting the ip_forward variable with the following command:
If you want to make the change persistent, you will need to edit the /etc/sysctl.conf file and add the following line to it:
To load your changes in sysctl.conf, you can use sysctl -p.
Masquerading between network interfaces falls outside the scope of Defguard’s responsibilities and must be handled by the system administrator. If your environment doesn’t already provide proper routing between the gateway’s interfaces, you may need to enable masquerading to ensure seamless communication.
As a shortcut, Defguard Gateway offers the --masquerade flag (or the DEFGUARD_MASQUERADE=true environment variable), which applies source NAT between all interfaces automatically, saving you from manually configuring masquerade rules at the system level. It results in this masquerade nftables rule:
The --masquerade option applies masquerading between all interfaces on the gateway, which may be more permissive than necessary in some environments. While convenient, this broad behavior might not align with more restrictive or segmented network designs. For greater control and tighter security, we recommend that administrators configure masquerading manually between only the interfaces that require it.
Defguard creates a forward chain in its namespace to control which forwarded packets are being allowed or blocked. This may interfere with your other nftables rules and chains.
By default this chain has the priority of filter (0). You can edit the priority by setting the DEFGUARD_FW_PRIORITY environment variable (or fw_priority config option) to chosen number, e.g. 1. The higher the priority, the later the chain runs in regard to your other forward chains.
Use the button to apply all the rules from "Pending Changes" section.
To create a new rule, use the button in the .
You can edit an existing rule by using the context menu and selecting "Edit" in the .
This setting is independent from the default location-level configuration.
Hit the button. You will be redirected back to the and the new rule should now be in the "Pending Changes" section.
Now just hit the button and the rule should be applied on the "office-berlin" location.
Under the hood, Access Control functionality uses to interact with the firewall and implement the rules. This means you'll need kernel version ≥ 5.10 to enable all kernel features required for proper operation.
