diff --git a/src/pages/how-to/traffic-events-logging.mdx b/src/pages/how-to/traffic-events-logging.mdx index c53d7434..f75fb6e4 100644 --- a/src/pages/how-to/traffic-events-logging.mdx +++ b/src/pages/how-to/traffic-events-logging.mdx @@ -35,7 +35,7 @@ NetBird would log the blocked event on the peer that refused the connection. traffic-events-p2p-diagram

-#### Successful P2P Connection Events Correlation +#### Successful P2P Connection Events NetBird helps you better understand connection flows by correlating related events and presenting them in a clear, organized manner. @@ -53,7 +53,11 @@ On the other side, the destination peer `server` receives the connection request following the disconnection from `Alice`. Since `server` allows the connection, the log includes the policy `IT Admins to Servers` that authorized the connection over the `ICMP` protocol. -#### Blocked P2P Connections Events Correlation + + Use the `P2P` filter in the table to view only peer-to-peer connection events. + + +#### Blocked P2P Connections Events If a connection is refused, NetBird logs the blocked event on the peer that denies the connection, in this case, `server`. The initiating peer `Alice` will still report the connection attempt but won't be aware that it was blocked. @@ -67,7 +71,7 @@ meaning all `HTTP` requests are intentionally not allowed. The screenshot below ### Peer-to-Network Resource Connections When a peer connects to a [network resource](/how-to/networks#resources), NetBird captures and logs the traffic -events for that connection on the peer that initiated the connection, and on the routing peer that connects the peer to +events for that connection on the peer that initiated the connection, and on the [routing peer](/how-to/networks#routing-peers) that connects the peer to the internal network resource. A slightly modified example of the CRM server connection scenario would be if instead of running the NetBird client on the CRM server, @@ -79,28 +83,38 @@ routed the connection to the CRM server. If the connection was blocked, NetBird traffic-events-routed-diagram

-#### Successful Peer-to-Network Resource Events Correlation +#### Successful Peer-to-Network Resource Events The screenshot below illustrates a successful connection from `Alice` to the network resource `CRM` running in the AWS VPC. The traffic is routed through a routing peer, which logs the connection event and reports it to the NetBird servers. The access is permitted by the policy `IT Admins to AWS Servers`, which allows connections over the `TCP` protocol on port `5432`. Note the `ROUTER` column in the table, which identifies the routing peer responsible for routing to the internal network resource. -You can filter such events by using the `Routed` filter in the table.

network-resource-succesful-connection

-#### Blocked Peer-to-Network Resource Events Correlation + + Use the `Routed` filter in the table to view only peer-to-network resource connection events. + + +#### Blocked Peer-to-Network Resource Events In the event of a blocked connection, the initiating peer logs the connection attempt, while the routing peer records the blocked event. The screenshot below demonstrates this behavior: the routing peer blocks a connection to the network resource `CRM` because the policy `IT Admins to AWS Servers` does not permit connections over the `HTTP` protocol on port `6432`. +You can see multiple blocked events from the routing peer, which indicates that the initiating peer `Alice` attempted to connect multiple times +in one TCP session, but the routing peer blocked all attempts.

network-resource-succesful-connection

+ + For all the examples above, we used the `nc` command to initiate the connection to the CRM server from the peer `Alice`. + E.g., `nc -v crm.netbird.cloud 5432`. + + ## Enabling Traffic Events Logging Traffic events logging feature is disabled by default. To enable it on the NetBird dashboard, navigate to `Settings > Networks`. @@ -121,12 +135,12 @@ at the kernel level. Be aware that enabling this option may lead to higher CPU u ## Log Retention -While in experimental mode, logs are retained for **7 days**. +While in experimental mode, logs are retained for **seven days**. Additionally, please note that the current API returns a maximum of **50,000 events**. We are actively working on expanding this limit in the coming days to support larger datasets and increased usage. ## Report rate -The events might take up to 10 minutes to become available via API and Dashboard. For some TCP connections, the full event cycle might take longer, depending on OS settings and connection termination. +The events might take up to **ten minutes** to become available via API and Dashboard. For some TCP connections, the full event cycle might take longer, depending on OS settings and connection termination. ## Enable Traffic Events Streaming to SIEM Systems