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: about/features-overview.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,23 +3,23 @@
3
3
### Remote Access with WireGuard® VPN 2FA/MFA:
4
4
5
5
*[**Multi-Factor Authentication**](../admin-and-features/wireguard/multi-factor-authentication-mfa-2fa/) using our [desktop client](https://defguard.net/client)
6
-
***multiple VPN Locations** (networks/sites) - with defined access (all users or only Admin group)
7
-
*multiple[Gateways](https://github.com/DefGuard/gateway) for each VPN Location ([**high availability/failove**](../deployment-strategies/high-availability-and-failover.md)**r**) - supported on a cluster of routers/firewalls for Linux, FreeBSD/PFSense/OPNSense
8
-
*import your current WireGuard server configuration (with a wizard!)
9
-
*_easy_ device setup by users themselves (self-service)
10
-
*automatic IP allocation
11
-
*kernel (Linux, FreeBSD/OPNSense/PFSense) & userspace WireGuard support
12
-
*dashboard and statistics overview of connected users/devices for admins
6
+
***Multiple VPN Locations** (networks/sites) - with defined access (all users or only Admin group)
7
+
*Multiple[Gateways](https://github.com/DefGuard/gateway) for each VPN Location ([**high availability/failove**](../deployment-strategies/high-availability-and-failover.md)**r**) - supported on a cluster of routers/firewalls for Linux, FreeBSD/PFSense/OPNSense
8
+
*Import your current WireGuard server configuration (with a wizard!)
9
+
*_Easy_ device setup by users themselves (self-service)
10
+
*Automatic IP allocation
11
+
*Kernel (Linux, FreeBSD/OPNSense/PFSense) & userspace WireGuard support
12
+
*[Dashboard and statistics overview](../admin-and-features/wireguard/network-overview.md) of connected users/devices for admins
13
13
14
-
_defguard is not an official WireGuard project, and WireGuard is a registered trademark of Jason A. Donenfeld._
14
+
_Defguard is not an official WireGuard project, and WireGuard is a registered trademark of Jason A. Donenfeld._
15
15
16
16
### Identity Management:
17
17
18
18
*#### [OpenID Connect](https://openid.net/developers/how-connect-works/) based SSO
19
19
* External [OpenID providers for login/account creation (Google/Microsoft/Custom)](../admin-and-features/external-openid-providers/)
20
20
* LDAP (tested on [OpenLDAP](https://www.openldap.org/)) synchronization
21
-
*nice UI to manage users
22
-
* Users **self-service** (besides typical data management, users can revoke access to granted apps, MFA, Wireguard, etc.)
21
+
*Nice UI to manage users
22
+
* Users **self-service** (besides typical data management, users can revoke access to granted apps, MFA, WireGuard, etc.)
Copy file name to clipboardExpand all lines: activity-log/README.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,19 +4,19 @@
4
4
This feature is available starting from version 1.4
5
5
{% endhint %}
6
6
7
-
The Activity Log provides a comprehensive view of user interactions within your Defguard instance. This allows you to monitor user behavior, troubleshoot issues, and maintain an audit trail of important activities.
7
+
The Activity Log provides a comprehensive view of user interactions within your Defguard instance. This allows you to monitor user behaviour, troubleshoot issues, and maintain an audit trail of important activities.
8
8
9
9
## Viewing Activity log events
10
10
11
11
Activity log is available as a dedicated page in Defguard core Web UI that's used to manage your instance.
12
12
13
-
To access it click the `Activity log` button in the navbar.
13
+
To access it, click the `Activity log` button in the navbar.
Copy file name to clipboardExpand all lines: activity-log/activity-log-streaming/activity-log-integrations/vector-integration-guide.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ The goal is to connect Defguard as [HTTP Source](https://vector.dev/docs/referen
11
11
12
12
### Setup Vector
13
13
14
-
For the sake of this example we will follow simple Docker deployment of Vector via Docker Compose but you most likely want to follow Vector's guide to [deploy ](https://vector.dev/docs/setup/deployment/)it in your infrastructure.
14
+
For the sake of this example we will follow simple Docker deployment of Vector via Docker Compose, but you most likely want to follow Vector's guide to [deploy ](https://vector.dev/docs/setup/deployment/)it in your infrastructure.
15
15
16
16
### Vector configuration
17
17
@@ -37,7 +37,7 @@ sinks:
37
37
38
38
This basic configuration adds an HTTP source named `defguard` and a console sink, which forwards all logs received from `defguard` to standard output.
39
39
40
-
Next add vector service to your **docker-compose.yaml** file.
40
+
Next, add vector service to your **docker-compose.yaml** file.
41
41
42
42
```yaml
43
43
vector:
@@ -50,7 +50,7 @@ Next add vector service to your **docker-compose.yaml** file.
50
50
- "8001:8001"
51
51
```
52
52
53
-
Make sure that new `vector` service is up and it loaded the configuration, it should print it in stdout:
53
+
Make sure that new `vector` service is up, and it loaded the configuration, it should print it in stdout:
54
54
55
55
```
56
56
INFO vector::app: Loading configs. paths=["/etc/vector/vector.toml"]
@@ -27,7 +27,7 @@ Access Control can be enabled for each location individually. To enable it:
27
27
28
28
## Default Access Control List Policy
29
29
30
-
Default policy defines how to treat network traffic (with regarding to resources) that was not explicitly specified in ACL rules:
30
+
Default policy defines how to treat network traffic (with regard to resources) that was not explicitly specified in ACL rules:
31
31
32
32
***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.
33
33
***Deny** - all traffic to network resources that is not regulated by one of the ACL rules will be blocked.
@@ -37,7 +37,7 @@ Default policy defines how to treat network traffic (with regarding to resources
37
37
Make sure ACL has been enabled (see above), otherwise the policy setting will not be inactive.
38
38
39
39
1. Navigate to **VPN Overview** > **Edit Location settings**
40
-
2. In **Location configuration** choose the desired option under **Default ACL Policy**.
40
+
2. In **Location configuration,** choose the desired option under **Default ACL Policy**.
@@ -68,7 +68,7 @@ Use the **Deploy pending changes** button to apply all the rules from **Pending
68
68
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.
69
69
{% endhint %}
70
70
71
-
The ACL list view also allows rule filtering by name, locations and other attributes
71
+
The ACL list view also allows rule filtering by name, locations, and other attributes
@@ -120,24 +120,24 @@ In Defguard, sources can be defined as one of three object types:
120
120
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.
121
121
122
122
{% hint style="warning" %}
123
-
This setting is independent from the default location-level [**Allowed groups**](../wireguard/create-your-vpn-network.md#allowed-groups) configuration.
123
+
This setting is independent of the default location-level [**Allowed groups**](../wireguard/create-your-vpn-network.md#allowed-groups) configuration.
124
124
125
125
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.
126
126
{% endhint %}
127
127
128
128
### How to define your ACL ruleset
129
129
130
-
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._
130
+
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._
131
131
132
132
#### Key Concepts:
133
133
134
134
* Each rule connects **who** (users, groups, or devices) to **what** (a resource address).
135
135
* At least one "allowed" source must always be specified - this defines who gets access.
136
136
* Optionally, you can **exclude** specific users, groups, or devices using the "denied" section.
137
137
* You can use this combination to create flexible rules, such as:\
138
-
\&#xNAN;_Allow everyone in the “Remote Workers” group except a few individuals access specific office network._
138
+
\&#xNAN;_Allow everyone in the “Remote Workers” group except a few individuals to access a specific office network._
139
139
140
-
This setup helps controlling access clearly and safely without worrying about lower-level network and firewall behavior.
140
+
This setup helps control access clearly and safely without worrying about lower-level network and firewall behaviour.
141
141
142
142
#### Details
143
143
@@ -153,51 +153,51 @@ This setup helps controlling access clearly and safely without worrying about lo
153
153
154
154
#### Allowing access for specific users
155
155
156
-
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.
156
+
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.
157
157
158
158
To do this, the following new rules have to be added:
159
159
160
160
* Navigate to **Access Control**.
161
161
* Click on **Add new** button.
162
-
* Name the rule under **Rule Name**: _Staff access Berlin_.
162
+
* Name the rule under **Rule Name**: _Staff access, Berlin_.
163
163
* Select _Office-Berlin_ in the **Locations** input.
164
-
* Under **Manual Input** > **IPv4/v6 CIDR range or adderess**, enter: _10.1.1.0/24_.
164
+
* Under **Manual Input** > **IPv4/v6 CIDR range or address**, enter: _10.1.1.0/24_.
165
165
* Add desired users in the **"Allowed Users/Groups/Devices** > **Users**.
(See [Implementation Details](../../enterprise/all-enteprise-features/access-control-list/firewall-internals.md) documentation to understand integrationn with system packet filtering.)
178
+
(See [Implementation Details](../../enterprise/all-enteprise-features/access-control-list/firewall-internals.md) documentation to understand integration with system packet filtering.)
179
179
180
180
#### Adding access exceptions for specific users
181
181
182
-
Let's build on the last example. The example defined a single rule that grants network access for two users. In this example we will block access for one specific user. But first let's rethink our approach.
182
+
Let's build on the last example. The example defined a single rule that grants network access for two users. In this example, we will block access for one specific user. But first, let's rethink our approach.
183
183
184
-
It may be tempting 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.
184
+
It may be tempting 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.
185
185
186
186
So what we will do is:
187
187
188
-
*we will define two groups:
188
+
*Define two groups:
189
189
*_Staff-Berlin_
190
190
*_Externals_
191
-
*we will add all the users that work in our _Berlin_ office to _Staff-Berlin_ group
192
-
*we will add all users we collaborate with in _Berlin_, but are not our direct employees, to the _Externals_ group
193
-
*we will allow all users in _Staff-Berlin_ group access to the network
194
-
*we will add an exception for the users in _Externals_ group so that they are not allowed to access the network
191
+
*Add all the users that work in our _Berlin_ office to _Staff-Berlin_ group
192
+
*Add all users we collaborate with in _Berlin_, but are not our direct employees, to the _Externals_ group
193
+
*Allow all users in _Staff-Berlin_ group access to the network
194
+
*Add an exception for the users in _Externals_ group so that they are not allowed to access the network
195
195
196
196
Once you have created appropriate groups and assigned the users, let's update the ACL rule. The rule should now:
197
197
198
-
*still be assigned to the _Office-Berlin_ location
199
-
*still define the destination resource address as `10.1.1.0/24`
200
-
*instead of specific users in the **Allowed Users** input, we now select the _Staff-Berlin_ group in the **Allowed Groups** input
201
-
*in**Denied Groups** input we should now select the _Externals_ group
198
+
*Still be assigned to the _Office-Berlin_ location
199
+
*Still define the destination resource address as `10.1.1.0/24`
200
+
*Instead of specific users in the **Allowed Users** input, we now select the _Staff-Berlin_ group in the **Allowed Groups** input
201
+
*In**Denied Groups** input we should now select the _Externals_ group
0 commit comments