diff --git a/src/pages/client/environment-variables.mdx b/src/pages/client/environment-variables.mdx
index 5f7d336d..db211819 100644
--- a/src/pages/client/environment-variables.mdx
+++ b/src/pages/client/environment-variables.mdx
@@ -46,7 +46,7 @@ To clear all saved service parameters (including env vars), run `sudo netbird se
| `NB_USE_NETSTACK_MODE` | All | Run WireGuard on top of a userspace TCP/IP stack (gVisor netstack) instead of a TUN device. Required for environments without TUN support (e.g. unprivileged containers). |
| `NB_NETSTACK_SKIP_PROXY` | All | When using netstack mode, do not start the built-in SOCKS5 proxy that exposes the WireGuard network to local applications. |
| `NB_SOCKS5_LISTENER_PORT` | All | Override the port the netstack SOCKS5 proxy listens on (default: `1080`). Only relevant when netstack mode is active. |
-| `NB_SOCKS5_LISTENER_ADDRESS` | All | Override the host/IP the netstack SOCKS5 proxy binds to (default: `127.0.0.1`). The proxy is unauthenticated and meant for local applications only, so it listens on loopback. Set this (e.g. to `0.0.0.0`) only when the proxy must be reachable from other hosts, such as a container gateway — this exposes an unauthenticated proxy on that address. Only relevant when netstack mode is active. |
+| `NB_SOCKS5_LISTENER_ADDRESS` | All | Override the host/IP the netstack SOCKS5 proxy binds to (default: `127.0.0.1`). The proxy is unauthenticated and meant for local applications only, so it listens on loopback. Set this (e.g. to `0.0.0.0`) only when the proxy must be reachable from other hosts, such as a container gateway. Doing so exposes an unauthenticated proxy on that address. Only relevant when netstack mode is active. |
## Firewall
diff --git a/src/pages/manage/activity/event-streaming/amazon-firehose.mdx b/src/pages/manage/activity/event-streaming/amazon-firehose.mdx
index 417fac9d..3b212234 100644
--- a/src/pages/manage/activity/event-streaming/amazon-firehose.mdx
+++ b/src/pages/manage/activity/event-streaming/amazon-firehose.mdx
@@ -75,7 +75,7 @@ the stream name with your own values):
## Create an Integration in NetBird
- Navigate to the [Integrations » Event Streaming](https://app.netbird.io/integrations?tab=event-streaming) tab in the NetBird dashboard
-
+
- On the `Amazon Data Firehose` card, click `Connect Amazon Data Firehose` or turn the card's toggle on to open the
@@ -84,17 +84,17 @@ fill in the field on that step.
- Step 1, `Select your Amazon Data Firehose region`: pick the region your stream lives in and click `Continue`. The dropdown
defaults to `US East (N. Virginia)`, so change it if your stream is elsewhere.
-
+
- Step 2, `Create your Firehose Stream`: under `Enter your Firehose stream name`, enter the stream you created in
[Create a Data Firehose Stream](#create-a-data-firehose-stream) and click `Continue`
-
+
- Step 3, `Create IAM credential`: enter the access key under `Enter your Access-Key`, the secret under `Enter your Secret-Key`,
both created in [Create an IAM User](#create-an-iam-user), and click `Connect`
-
+
All four values (region, stream name, access key, secret key) are required. Once you click `Connect`, the integration is created
diff --git a/src/pages/manage/activity/event-streaming/amazon-s3.mdx b/src/pages/manage/activity/event-streaming/amazon-s3.mdx
index 0edfc3fa..444c2865 100644
--- a/src/pages/manage/activity/event-streaming/amazon-s3.mdx
+++ b/src/pages/manage/activity/event-streaming/amazon-s3.mdx
@@ -74,7 +74,7 @@ with your own bucket name):
## Create an Integration in NetBird
- Navigate to the [Integrations » Event Streaming](https://app.netbird.io/integrations?tab=event-streaming) tab in the NetBird dashboard
-
+
- On the `Amazon S3` card, click `Connect Amazon S3` or turn the card's toggle on to open the `Connect NetBird with Amazon S3` wizard.
@@ -82,17 +82,17 @@ The wizard has three steps, and each step's button stays disabled until you fill
- Step 1, `Select your Amazon S3 region`: pick the region your bucket lives in and click `Continue`. The dropdown defaults to
`US East (N. Virginia)`, so change it if your bucket is elsewhere.
-
+
- Step 2, `Create your S3 Bucket`: under `Enter your S3 Bucket name`, enter the bucket you created in
[Create an S3 Bucket](#create-an-s3-bucket) and click `Continue`
-
+
- Step 3, `Create IAM credential`: enter the access key under `Enter your Access-Key`, the secret under `Enter your Secret-Key`,
both created in [Create an IAM User](#create-an-iam-user), and click `Connect`
-
+
All four values (region, bucket name, access key, secret key) are required. Once you click `Connect`, the integration is created
@@ -126,7 +126,7 @@ containing the following events:
- `integration created`
-
+
```json
diff --git a/src/pages/manage/activity/event-streaming/datadog.mdx b/src/pages/manage/activity/event-streaming/datadog.mdx
index 7db3d843..7a49bc73 100644
--- a/src/pages/manage/activity/event-streaming/datadog.mdx
+++ b/src/pages/manage/activity/event-streaming/datadog.mdx
@@ -70,18 +70,18 @@ Datadog sites:
- Navigate to the `Integrations` » `Event Streaming` tab in the [NetBird Dashboard](https://app.netbird.io/integrations?tab=event-streaming)
-
+
- On the `Datadog` card, click `Connect Datadog` or switch the card's toggle on. Either one opens the
`Connect NetBird with Datadog` wizard.
- Under `Select your Datadog region`, choose your site from the dropdown and click `Continue`
-
+
- Under `Get your Datadog API Key`, paste the API key you created above into the input field and click `Connect`
-
+
The API key is the only value you type in. `Connect` stays disabled until the field is filled, and NetBird does not check
@@ -96,7 +96,7 @@ service in the Log Explorer:
- `integration created`
-
+
The `integration test` event is sent to validate whether the provided credentials are correct and NetBird can stream events.
diff --git a/src/pages/manage/activity/event-streaming/generic-http.mdx b/src/pages/manage/activity/event-streaming/generic-http.mdx
index 27988e80..ee6d1e78 100644
--- a/src/pages/manage/activity/event-streaming/generic-http.mdx
+++ b/src/pages/manage/activity/event-streaming/generic-http.mdx
@@ -4,6 +4,10 @@ The Generic HTTP integration streams your NetBird audit and traffic events to an
For every event, NetBird sends a POST request to the endpoint you configure. You control the request headers and, optionally, the shape of the body.
+If your destination is Datadog, Amazon S3, or Amazon Data Firehose, use its own card instead. Those integrations ask
+for a region and credentials and handle the endpoint and payload for you, so there is nothing to template and nothing
+to keep in sync. Reach for Generic HTTP when no dedicated card exists for where you are sending events.
+
Event streaming is available in NetBird Cloud under the [Business plan](https://www.netbird.io/pricing?utm_source=docs&utm_content=event-streaming) and in licensed self-hosted Enterprise deployments. The open source management server does not serve the event streaming API, so the integration cards stay locked there.
diff --git a/src/pages/manage/activity/event-streaming/index.mdx b/src/pages/manage/activity/event-streaming/index.mdx
index a2694b96..de75c528 100644
--- a/src/pages/manage/activity/event-streaming/index.mdx
+++ b/src/pages/manage/activity/event-streaming/index.mdx
@@ -1,7 +1,7 @@
# Stream Audit and Traffic Events to Third-Party Services
-
+
Event Streaming forwards your NetBird activity to an external destination as the events occur. Destinations include SIEM
diff --git a/src/pages/manage/activity/event-streaming/sentinelone-data-lake.mdx b/src/pages/manage/activity/event-streaming/sentinelone-data-lake.mdx
index 425bb319..a5508dd1 100644
--- a/src/pages/manage/activity/event-streaming/sentinelone-data-lake.mdx
+++ b/src/pages/manage/activity/event-streaming/sentinelone-data-lake.mdx
@@ -31,7 +31,7 @@ Before you start configuring the `Generic HTTP` integration for SentinelOne Sing
- Click **Copy to Clipboard** and store this token securely. You will need this token when configuring the integration in NetBird.
-
+
## Get the HEC Ingestion URL
@@ -48,7 +48,7 @@ to find and copy the HTTP Event Collector base URL from the documentation page.
5. Click `Continue`.
-
+
6. Leave the `Headers` tab empty unless your tenant requires extra headers, then click `Continue`. Do not add your own `Authorization` header here, because it conflicts with the `Bearer Token` method selected on the previous tab and blocks the save.
@@ -71,7 +71,7 @@ to find and copy the HTTP Event Collector base URL from the documentation page.
8. Click `Connect`. When you are editing an integration that already exists, the button reads `Save Changes` instead.
-
+
@@ -91,7 +91,7 @@ Saving the integration makes NetBird post a synthetic test event to the endpoint
- Look for an `integration test event for generic http endpoint` message followed by an `integration created` message, and confirm that the `id`, `initiator_id`, `target_id`, and `time` fields carry the values your template produced
-
+
The integration is now set up and ready to stream network activity events to SentinelOne Singularity Data Lake.
diff --git a/src/pages/manage/activity/index.mdx b/src/pages/manage/activity/index.mdx
index 51642c1a..ab8c82f4 100644
--- a/src/pages/manage/activity/index.mdx
+++ b/src/pages/manage/activity/index.mdx
@@ -1,8 +1,11 @@
# Audit Events Logging
-The Audit events logging functionality in NetBird allows you to observe and track changes to your network infrastructure.
-This includes events such as when a new machine or user has joined your network, when access control policies have been modified,
-and many other key network events.
+Networks drift. A policy gets loosened, a setup key gets shared, someone is added to a group that grants more access than
+anyone intended. Weeks later the question is who changed it, and when.
+
+Audit events answer that. NetBird records every configuration change made on the Management server, such as a peer or user
+joining, an access control policy being modified, or a setup key being revoked, and keeps them in a searchable feed with the
+person or system that made each change.
## Related Video Content
@@ -22,7 +25,7 @@ This view provides a centralized log of network events.
-
+
Each entry in the feed shows who triggered the event (name and email address), when it happened, and a description of the change with the
diff --git a/src/pages/manage/activity/traffic-events-logging.mdx b/src/pages/manage/activity/traffic-events-logging.mdx
index ca87a739..1a9053e8 100644
--- a/src/pages/manage/activity/traffic-events-logging.mdx
+++ b/src/pages/manage/activity/traffic-events-logging.mdx
@@ -1,5 +1,13 @@
# Traffic Events Logging
+Access policies tell NetBird which connections are allowed. They do not tell you what actually happened. When a
+connection fails for no obvious reason, or an auditor asks who reached the production database last month, you need a
+record of the attempts themselves.
+
+Traffic events are that record. Each event describes one connection, peer-to-peer, site-to-site, or peer-to-resource:
+who started it, what they reached, when, over which protocol and port, how much data moved, and which policy allowed
+or blocked it.
+
This feature is available in NetBird Cloud under the [Business plan](https://www.netbird.io/pricing?utm_source=docs&utm_content=traffic-events) and in licensed self-hosted Enterprise deployments with traffic flow enabled.
Traffic events are experimental, so functionality and behavior may evolve, including how data is collected and reported.
@@ -11,14 +19,6 @@ On self-hosted deployments, traffic flow is an opt-in part of the [Enterprise st
-The traffic events logging functionality enables comprehensive monitoring and analysis of connections across your infrastructure.
-It captures network activity, including peer-to-peer, site-to-site, peer-to-resource, and other network traffic events.
-
-It provides detailed visibility into connections and network traffic flow, helping to answer key questions such as who initiated
-the connection, what resource was accessed, when it happened, where it originated, and why it was allowed. By enhancing
-network monitoring capabilities, it strengthens security measures and delivers actionable operational insights, empowering
-you to better manage and secure your environment.
-
## How Traffic Events Logging Works
NetBird offers flexibility as a peer-to-peer (p2p) overlay network and a remote network access solution. You can use NetBird to connect
@@ -36,7 +36,7 @@ connection on both the user's machine and the CRM server. If the connection was
NetBird would log the blocked event on the peer that refused the connection.
-
+
#### Successful P2P Connection Events
@@ -47,7 +47,7 @@ For example, in a successful peer-to-peer connection scenario, a user initiates
This is illustrated in the screenshot below.
-
+
You'll see two aggregated flow records, one reported by each peer (source and destination). The record from `Alice` counts the connection start and end from the initiator's perspective.
@@ -67,7 +67,7 @@ The initiating peer `Alice` will still report the connection attempt but won't b
In this scenario, the `IT Admins to Servers` policy is configured to allow only ping requests (`ICMP`),
meaning `TCP` connections are intentionally not allowed. The screenshot below illustrates this behavior.
-
+
### Peer-to-Network Resource Connections
@@ -82,7 +82,7 @@ and port 443, NetBird would log the traffic events for that connection on the us
routed the connection to the CRM server. If the connection was blocked, NetBird would log the blocked event on the routing peer.
-
+
#### Successful Peer-to-Network Resource Events
@@ -93,7 +93,7 @@ The access is permitted by the policy `IT Admins to AWS Servers`, which allows c
Note the `Router` column in the table, which identifies the routing peer responsible for routing to the internal network resource.
-
+
@@ -108,7 +108,7 @@ the policy `IT Admins to AWS Servers` does not permit `TCP` connections on port
The routing peer's aggregate shows the number of dropped attempts, so repeated application retries increase the drop count instead of creating one top-level row for every attempt.
-
+
@@ -146,7 +146,7 @@ You can optionally turn on `Enable Traffic Reporting (Kernel)` to capture packet
-
+
### Limiting Traffic Events to Specific Groups
@@ -159,7 +159,7 @@ You can scope traffic events logging to only the peers that belong to specific g
To configure this setting, navigate to `Settings > Networks`, and in the `Experimental` section open the `Limit To Specific Groups` selector
below `Enable Traffic Events`, choose the groups you want to include, and click `Save Groups`.
-
+
## Log Retention
@@ -312,14 +312,14 @@ You can use endpoint addresses, destination ports, and the other flow fields to
The peer `example-laptop.local` initiates a connection to the Web server on destination port TCP/80. A successful aggregate has non-zero start and end counters and totals the packets and bytes transferred in the reporting window:
-
+
Use the reporter, source, destination, direction, protocol, and destination port to align the two perspectives. An end can be reported in a later window when the operating system keeps the TCP session open.
The UDP connection is very similar:
-
+
UDP is stateless, so its end counter is only updated after the client observes 30 seconds of inactivity on the connection.
@@ -329,12 +329,12 @@ When a connection is blocked, you may see similar entries to the following event
**TCP**:
-
+
**UDP**:
-
+
On the refusing side, retries increase `num_of_drops`; the client does not record a successful start or end for traffic it rejected. Drops are always recorded as `INGRESS`, because a peer can only observe traffic that it refused to accept.
@@ -344,7 +344,7 @@ On the refusing side, retries increase `num_of_drops`; the client does not recor
### Viewing ICMP connections
ICMP events are similar to TCP and UDP events. The main difference is that ICMP doesn't have ports:
-
+
ICMP is grouped by ICMP type and does not use ports. Its end counter is only updated after 30 seconds of inactivity.
@@ -354,17 +354,17 @@ Routed events follow the same pattern as P2P events. The main difference is that
**ICMP**:
-
+
**TCP**:
-
+
For routed aggregates, the source or destination can be a resource or network route, and the `Router` column identifies the routing peer that reported it. For domain based resources, the endpoint is resolved on the peer that performed the DNS resolution, so one side of the flow can show the resource name while the other side shows only the address with type `UNKNOWN`.
For site-2-site connections, the events will be similar to the above examples, but you will see a routing peer for each event:
-
+
## Limitations