You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: enterprise/all-enteprise-features/access-control-list/README.md
+66-42Lines changed: 66 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,52 +4,70 @@ icon: user-shield
4
4
5
5
# Access Control List
6
6
7
-
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. 
7
+
{% hint style="info" %}
8
+
Access Control List feature is available in Defguard Core v1.3.0 and Defgaurd Gateway v1.3.0.
8
9
9
-
{% hint style="warning" %}
10
-
Access Control is an [enterprise feature](../../license.md). To use it you'll need to [purchase a license](../../license.md#purchasing-the-license) or ensure your deployment does not [exceed the limits](../../license.md#enterprise-is-free-up-to-certain-limits).
10
+
Defguard Gateway v1.3.0 supports Linux machines with [NFTables](https://nftables.org/).
11
+
Defguard Gateway v1.4.0 supports FreeBSD, NetBSD, and macOS machines with Packet Filter (PF).
12
+
{% endhint %}
11
13
12
-
Access Control is available in Defguard version ≥ 1.3.0 and Gateway version ≥ 1.3.0
14
+
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.
15
+
16
+
{% hint style="warning" %}
17
+
Access Control is an [enterprise feature](../../license.md). To be able to use it, it is requireed to [purchase a license](../../license.md#purchasing-the-license), or ensure your deployment does not [exceed the limits](../../license.md#enterprise-is-free-up-to-certain-limits).
13
18
{% endhint %}
14
19
15
-
## How to enable Access Control List functionality
20
+
###How to enable Access Control List functionality
16
21
17
-
Access Control is enabled / disabled for each location individually. To enable it, go to location settings (you'll find the .png>) button on the [network overview](../../../admin-and-features/features-and-configuration/wireguard/network-overview.md) page).
22
+
Access Control can be enabled for each location individually. To enable it:
18
23
19
-
There are two relevant options in the **"Location configuration"** section:
24
+
1. Navigate to **VPN Overview** > **Edit Location settings**
25
+
2. In **Location configuration** section select **Enable ACL for this location**.
Select the checkbox to enable ACL for the location.
30
+
**You should also set the default ACL policy for the location** (see below).
31
+
32
+
## Default Access Control List Policy
24
33
25
-
**You should also set the default ACL policy for the location.**
34
+
Default policy defines how to treat network traffic (with regarding to resources) that was not explicitly specified in ACL rules:
26
35
27
-
Default policy defines what happens with traffic to resources that were not explicitly specified in your ACL rules:
36
+
***Allow** - users and devices connected to a location will be able to access all resources within the network, if the resource access is not modified by one of ACL rules.
37
+
***Deny** - all traffic to network resources that is not regulated by one of the ACL rules will be blocked.
28
38
29
-
* 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.
30
-
* Deny - all traffic to network resources that is not regulated by one of the ACL rules will be dropped
39
+
### How to define the default ACL Policy
40
+
41
+
Make sure ACL has been enabled (see above), otherwise the policy setting will not be inactive.
42
+
43
+
1. Navigate to **VPN Overview** > **Edit Location settings**
44
+
2. In **Location configuration** choose the desired option under **Default ACL Policy**.
**Access Control List** view displays all the rules defined in your system. The list is split into two sections. 
53
+
**Access Control List** view displays all the rules defined in your system. The list is split into two sections.
37
54
38
-
**"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.
55
+
**Deployed Rules** section displays the rules that have already been applied. Those rules should be in effect on relevant locations if the Gateway–Core connection is intact.
39
56
40
57
{% hint style="warning" %}
41
-
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.
58
+
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**, meaning rules will be applied once the connection is restored.
42
59
{% endhint %}
43
60
44
-
**"Pending Changes"** section displays all the rules that have not yet been applied to locations. This includes:
61
+
**Pending Changes** section displays all the rules that have not yet been applied to locations. This includes:
45
62
46
63
* new rules
47
64
* modified rules
48
65
* deleted rules
49
66
50
-
Use the .png>) button to apply all the rules from **"Pending Changes"** section.
67
+
Use the .png>) button to apply all the rules from **Pending Changes** section.
51
68
52
69
{% hint style="info" %}
70
+
53
71
## Batch rule application
54
72
55
73
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.
@@ -61,7 +79,7 @@ The ACL list view also allows rule filtering by name, locations and other attrib
61
79
62
80
## How to add and modify ACL rules
63
81
64
-
To create a new rule, use the .png>) button in the [ACL List View](./#list-of-acl-rules). 
82
+
To create a new rule, use the .png>) button in the [ACL List View](./#list-of-acl-rules).
65
83
66
84
You can edit an existing rule by using the .png>) context menu and selecting **"Edit"** in the [ACL List View](./#list-of-acl-rules)**.**
67
85
@@ -73,7 +91,7 @@ You can edit an existing rule by using the ![](<../../../.gitbook/assets/image (
73
91
74
92
The ACL form consists of three main sections:
75
93
76
-
#### **Basic rule configuration**
94
+
#### Basic rule configuration
77
95
78
96
* rule name
79
97
* locations where the rule should be applied
@@ -83,18 +101,18 @@ The ACL form consists of three main sections:
83
101
Each rule in Defguard can be **enabled** or **disabled** individually. When a rule is disabled, it remains stored in the system but is not applied to any locations, meaning it has no effect on access control until re-enabled. This allows administrators to temporarily deactivate rules without deleting them, making it easy to toggle access policies as needed.
84
102
{% endhint %}
85
103
86
-
#### **Destination**
104
+
#### Destination
87
105
88
106
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.
89
107
90
108
* 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:
* Protocols that will be affected by the rule. All by default. Defguard ACL currently supports TCP, UDP and ICMP protocols.
96
114
97
-
#### **Allowed and Denied sources**
115
+
#### Allowed and Denied sources
98
116
99
117
This section lets you define which traffic sources should be granted or denied access - essentially the **"source"** side of a firewall rule.
100
118
@@ -107,31 +125,31 @@ In Defguard, sources can be defined as one of three object types:
107
125
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.
108
126
109
127
{% hint style="warning" %}
110
-
This setting is independent from the default location-level [**Allowed groups**](../../../admin-and-features/features-and-configuration/wireguard/create-your-vpn-network.md#allowed-groups) configuration. 
128
+
This setting is independent from the default location-level [**Allowed groups**](../../../admin-and-features/features-and-configuration/wireguard/create-your-vpn-network.md#allowed-groups) configuration.
111
129
112
130
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.
113
131
{% endhint %}
114
132
115
133
### How to define your ACL ruleset
116
134
117
-
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.”_
135
+
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._
118
136
119
137
#### Key Concepts:
120
138
121
139
* Each rule connects **who** (users, groups, or devices) to **what** (a resource address).
122
140
* At least one "allowed" source must always be specified - this defines who gets access.
123
141
* Optionally, you can **exclude** specific users, groups, or devices using the "denied" section.
124
142
* You can use this combination to create flexible rules, such as:\
125
-
&#xNAN;_Allow everyone in the “Remote Workers” group except a few individuals access to specific office network._
143
+
_Allow everyone in the “Remote Workers” group except a few individuals access specific office network._
126
144
127
-
This setup helps you control access clearly and safely without worrying about lower-level network and firewall behavior.
145
+
This setup helps controlling access clearly and safely without worrying about lower-level network and firewall behavior.
128
146
129
147
#### Details
130
148
131
-
* 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.
132
-
***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.
133
-
* A **destination address** is required in each rule - specifying only ports and/or protocols is not allowed.
134
-
***Ports and protocols** are optional. If specified, traffic is allowed _only_ on those ports/protocols—everything else will be blocked.
149
+
* 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.
150
+
***Default policy setting** at location level does not affect traffic covered by ACL rules. It applies only to traffic targeting addresses not matched by any ACL rule.
151
+
* A **destination address** is required in each rule – specifying only ports and/or protocols that are not allowed.
152
+
***Ports and protocols** are optional. If specified, traffic is allowed _only_ on those ports/protocols; everything else is blocked.
135
153
* Each ACL results in two firewall rules:
136
154
* An **ALLOW** rule for the allowed sources.
137
155
* A **DENY** rule to block all other traffic to that destination.
@@ -140,27 +158,33 @@ This setup helps you control access clearly and safely without worrying about lo
140
158
141
159
#### Allowing access for specific users
142
160
143
-
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.
161
+
In this scenario we will allow specific users to access the 10.1.1.0/24 network, assuming the users connect through _Office-Berlin_ location.
144
162
145
-
Do do this you will add new rule with:
163
+
To do this, the following new rules have to be added:
146
164
147
-
* office-berlin location selected in the **"Locations"** input
148
-
***"10.1.1.0/24"** CIDR in the destination input
149
-
* Appropriate users in the **"Allowed Users/Groups/Devices->Users"** input
165
+
* Navigate to **Access Control**.
166
+
* Click on **Add new** button.
167
+
* Name the rule under **Rule Name**: _Staff access Berlin_.
168
+
* Select _Office-Berlin_ in the **Locations** input.
169
+
* Under **Manual Input** > **IPv4/v6 CIDR range or adderess**, enter: _10.1.1.0/24_.
170
+
* Add desired users in the **"Allowed Users/Groups/Devices** > **Users**.
Hit the .png>) button. You will be redirected back to the [ACL List View](./#list-of-acl-rules) and the new rule should now be in the **"Pending Changes"** section.
175
+
You will be redirected back to the [ACL List View](./#list-of-acl-rules) and the new rule should now be in the **Pending Changes** section.
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:
187
+
All applied rules are deployed to Defguard Gateway. This means that the firewall on the Gateway that handles the _Office-Berlin_ location should contain appropriate [NFTables](https://nftables.org/) rules that implement the specified requirements. Let's see how this looks like in practice. Below is the `nftables list ruleset` output:
164
188
165
189
```
166
190
...
@@ -175,11 +199,11 @@ table inet DEFGUARD {
175
199
...
176
200
```
177
201
178
-
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. 
202
+
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.
179
203
180
204
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.
181
205
182
-
Finally the two lines that directly deal with our requirement to allow the two users into the network. 
206
+
Finally the two lines that directly deal with our requirement to allow the two users into the network.
183
207
184
208
```
185
209
ip saddr { 10.100.200.155-10.100.200.156 } ip daddr { 10.1.1.0/24 } counter packets 0 bytes 0 accept comment "ACL 132 - Office access Berlin ALLOW"
@@ -270,4 +294,4 @@ chain FORWARD {
270
294
}
271
295
```
272
296
273
-
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. 
297
+
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.
0 commit comments