> For the complete documentation index, see [llms.txt](https://learn.netmaker.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.netmaker.io/features/telemetry-and-logging/activity/network-flow-logs.md). # Network Flow Logs ## Overview Traffic logs offer real-time visibility into network traffic on your Netmaker network, allowing you to monitor connections, analyze traffic patterns, and troubleshoot issues with detailed connection logs **PRO FEATURE** Traffic logs are available only on the Netmaker Business plan **ENABLING TRAFFIC LOGS** If Traffic Logs are not included in your plan, it must be enabled by the Netmaker team. To request activation: **Contact Form:** **Status:** BETA ## What are Traffic Logs? Traffic Logs capture detailed information about network connections flowing through your Netmaker network. Each log entry records the source, destination, protocol, ports, traffic direction, and data volume for comprehensive network visibility. ### Key Benefits * Real-time visibility into all network traffic * Troubleshoot connectivity issues with detailed connection data * Monitor traffic patterns and bandwidth usage * Identify suspicious activity or unauthorised connections ### Understanding the Traffic Logs Interface Global Insights View ```plaintext Sidebar → Analytics → Activity Tab → Traffic Logs ```
Each traffic log entry displays detailed information about a network event. Below is a breakdown of all components you'll see in a log entry: ### Log Entry Components Each traffic log entry displays detailed information about a network event: | Component | Description | Example | | --------------- | ---------------------------------------------- | ---------------------------------------------------- | | Event | Timestamp, end time, node name, and direction | 9:03 AM, End: 9:03 AM, Node: inetgw, Inbound | | Source | Origin of traffic (Node, User, External, etc.) | debian (node), 100.102.137.9:54618, | | Protocol & Port | Network protocol and destination port | TCP 443, UDP 53, ICMP | | Destination | Target of traffic | inetgw (node), 140.82.113.26 | | Traffic | Data transferred (download/upload) | ↓ 60 B, ↑ 40 B | *** ### Domain Visibility in Traffic Logs Traffic Logs now include **domain names** for external destinations, making it easier to identify services and endpoints without relying solely on IP addresses. This enhancement improves: * Readability of logs * Faster troubleshooting * Better security analysis Instead of seeing only an IP address: ``` 34.160.111.145:443 ``` You may now see: ``` api.example.com 34.160.111.145:443 ``` **Example:** * Before: \ `140.82.113.26:443` * After: \ `github.com`\ `20.26.156.215:443`
**Figure:** Traffic Logs showing domain names and addresses for external connections. ### Component Details **Event Information:** * **Timestamp:** Exact time the traffic event occurred (format: `HH:MM AM/PM`) * **End Time:** When the traffic event is completed (format: `End: HH:MM AM/PM`) * **Node:** The node that generated or received the traffic (format: `Node: [node-name]`) * **Direction:** Traffic flow - **Inbound** (coming into node) or **Outbound** (leaving node) **Source Types:** * **Node:** Internal network node (e.g., `debian`, `inetgw`) * **User:** User devices (e.g., `majdi@netmaker.io`) * **Config Files:** Configuration-related traffic * **External:** External IP addresses outside your network * **Egress Route:** Traffic through egress gateways **Protocol Types:** * **TCP** - Transmission Control Protocol (reliable, connection-oriented) * **UDP** - User Datagram Protocol (fast, connectionless) * **ICMP** - Internet Control Message Protocol (network diagnostics) **Destination Types:** * **Node:** Internal network node * **User:** User endpoint * **Config Files:** Configuration endpoints * **External:** External IP addresses (e.g., `140.82.113.26`) * **Egress Route:** Egress gateway destinations **Traffic Volume Indicators:** * **↓ (Download):** Data received by the source node * **↑ (Upload):** Data sent by the source node * **Units:** B (bytes), KiB (kibibytes), MiB (mebibytes) ## Reading Traffic Log Entries
### Example 1: Internal Node Communication (Inbound) ![](/files/og4FTRwdmtkYnA9ZZAVL) ```plaintext EVENT: 9:51 AM End: 9:51 AM Node: inetgw Direction: Inbound SOURCE PROTOCOL & PORT DESTINATION TRAFFIC debian TCP inetgw ↓ 60.00 (B) 100.102.137.9:44006 443 100.102.137.4:443 ↑ 40.00 (B) ``` **How to Read This:** 1. Reported by the i**netgw node** 2. **When:** The event occurred at 9:51 AM and ended at 9:51 AM 3. **Where:** Traffic passed through the `inetgw` node 4. **Direction:** Inbound (coming into inetgw) 5. **Source:** The `debian` node from IP 100.102.137.9, port 44006 6. **Protocol:** TCP on port 443 (HTTPS) 7. **Destination:** The `inetgw` node at IP 100.102.137.4, port 443 8. **Data Transfer:** 60 bytes received (↓), 40 bytes sent (↑) **Interpretation:** **The debian node initiated** a secure HTTPS connection to the inetgw gateway, receiving 60 bytes and sending 40 bytes of data. This is typical of a small API call or status check. ### Example 2: Same Connection from Source Perspective (Outbound) ![](/files/7uMCKSvRzwpwwfS9Ho7w) ```plaintext EVENT: 9:51 AM End: 9:51 AM Node: debian Direction: Outbound SOURCE PROTOCOL & PORT DESTINATION TRAFFIC debian TCP inetgw ↓ 40.00 (B) 100.102.137.9:44006 443 100.102.137.4:443 ↑ 60.00 (B) ``` **How to Read This:** 1. Reported by the **debian node** 2. **When:** 9:51 AM (same event as Example 1) 3. **Where:** Traffic originated from the `debian` node 4. **Direction:** Outbound (leaving debian) 5. **Source:** The `debian` node at IP 100.102.137.9, port 44006 6. **Protocol:** TCP on port 443 (HTTPS) 7. **Destination:** The `inetgw` gateway at IP 100.102.137.4, port 443 8. **Data Transfer:** 40 bytes received (↓), 60 bytes sent (↑) **Interpretation:** This is the same connection as Example 1, but reported by the **debian node.** Notice how the traffic values are reversed (↓40B/↑60B vs ↓60B/↑40B) ### Example 3: User Connection to External Service ![](/files/WxlQKG6Kg0wKHikiqRiZ) ```plaintext EVENT: 9:50 AM End: 9:51 AM Node: inetgw Direction: Inbound SOURCE PROTOCOL & PORT DESTINATION TRAFFIC majdi@netmaker.io TCP 34.160.111.145 ↓ 2.36 (KiB) 100.102.137.21:38532 443 34.160.111.145:443 ↑ 4.03 (KiB) ``` **How to Read This:** 1. Reported by the **inetgw node** 2. **When:** Event started at 9:50 AM and ended at 9:51 AM 3. **Who:** User `majdi@netmaker.io` initiated the connection 4. **Where:** Traffic routed through the `inetgw` node (gateway) 5. **Direction:** Inbound through the gateway 6. **Source:** User at IP 100.102.137.21, port 38532 7. **Protocol:** TCP on port 443 (HTTPS) 8. **Destination:** External server at IP 34.160.111.145, port 443 9. **Data Transfer:** 2.36 KiB received (↓), 4.03 KiB sent (↑) **Interpretation:** User connected through the inetgw gateway to an external server on HTTPS. The user downloaded 2.36 KiB and uploaded 4.03 KiB, suggesting they sent more data than they received—typical of uploading data or submitting form content to an external service. ## Common Traffic Patterns ### Small Data Transfers (< 1 KiB) **What it means:** Control messages, API calls, heartbeats, status checks **Examples:** * ↓ 60.00 (B) / ↑ 40.00 (B) * TCP port 443 connections with minimal data * Quick request/response patterns **Typical scenarios:** * Health checks between nodes * Authentication requests * Configuration updates * DNS queries ### Medium Data Transfers (1-100 KiB) **What it means:** Web pages, API responses, small files **Examples:** * ↓ 4.33 (KiB) / ↑ 4.84 (KiB) * HTTP/HTTPS web page loads * JSON data exchanges **Typical scenarios:** * Loading web dashboards * API data retrieval * Configuration file transfers * Log uploads ### Large Data Transfers (> 100 KiB) **What it means:** File transfers, media, backups **Examples:** * ↓ 2.5 (MiB) / ↑ 1.2 (MiB) * File downloads/uploads * Database syncs **Typical scenarios:** * Software updates * Backup operations * Video streaming * Large file transfers ## Using the Filter Feature
{% stepper %} {% step %} Click the "Filter" button at the top of the Traffic Logs panel {% endstep %} {% step %} Select your filter criteria: Time Range, Protocol, Direction, Source, Destination Types {% endstep %} {% step %} Apply filters to see refined results {% endstep %} {% step %} Reset to defaults to return to full view {% endstep %} {% endstepper %} ## Data Volume Reference ### Understanding Size Units **Bytes (B):** * Range: 1 - 999 B * Typical for: Control messages, handshakes, small requests * Examples: TCP SYN packets, HTTP headers, status checks **Kibibytes (KiB):** * 1 KiB = 1,024 bytes * Range: 1 - 999 KiB * Typical for: Web pages, API responses, small files * Examples: HTML pages, JSON data, small images **Mebibytes (MiB):** * 1 MiB = 1,024 KiB = 1,048,576 bytes * Range: 1+ MiB * Typical for: Large files, media, backups * Examples: Videos, software updates, database dumps ### Typical Traffic Volumes by Service | Service | Typical Size | Example | | -------------- | -------------: | --------------------- | | TCP Handshake | 40-100 B | ↓ 60 B / ↑ 40 B | | DNS Query | 50-150 B | ↓ 120 B / ↑ 80 B | | HTTP Header | 200-800 B | ↓ 500 B / ↑ 300 B | | Small API Call | 1-10 KiB | ↓ 4.5 KiB / ↑ 2.1 KiB | | Web Page | 10-500 KiB | ↓ 250 KiB / ↑ 15 KiB | | Image | 50 KiB - 5 MiB | ↓ 1.2 MiB / ↑ 500 B | | Video Stream | 1-10+ MiB/sec | ↓ 8 MiB / ↑ 100 KiB | ## Summary Traffic Logs provides essential visibility into your network communications: * Real-time monitoring of all network traffic * Detailed information about each connection * Flexible filtering to find relevant events * Security monitoring to detect threats * Performance troubleshooting to identify issues * Compliance auditing to document activity **To get started:** Please --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://learn.netmaker.io/features/telemetry-and-logging/activity/network-flow-logs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.