Packet captures at the edge

Capturing packets when the network is everywhere

Packet captures have long been the standard tool for troubleshooting network problems and analyzing suspicious traffic. Historically, that meant logging into the single router or firewall that all traffic flowed through and running something like tcpdump to record packets to a file. But as network functions move off dedicated hardware and into distributed, cloud-native services, the traffic no longer funnels through one device. It is fragmented across many physical and virtual appliances, often in different locations, and many of those devices do not support packet captures at all. Stitching together a complete picture of traffic from such a fractured environment is, in practice, nearly impossible.

Cloudflare is addressing this with the general availability of on-demand packet captures from its global network. For customers using Magic Transit and Magic WAN, all public and private IP traffic already routes through Cloudflare’s infrastructure, which acts as a single, distributed router and firewall. That same position now enables captures across a customer’s entire network, delivered back in one place.

What a packet capture is used for

A packet capture file contains every packet that a network device—typically a router or firewall—observed during a set time window. It is a debugging and security instrument used in a few common scenarios:

• Troubleshooting reachability: An engineer who gets reports of intermittent connectivity from a specific user can start a capture filtered to that user’s source IP. The resulting file records every packet received from that device, which can then be compared against captures taken from the user’s side of the path, along with traffic logs and analytics, to isolate the fault.
• Analyzing attack traffic: A sudden, unexplained spike in traffic may be an attempted attack. A capture records the packets as they hit the network, and inspecting them reveals whether they are legitimate. If the payloads are randomly generated garbage, the engineer can write a firewall rule that blocks that pattern from entering the network.

How the capture pipeline works

Customers request a capture through the Packet Captures API, supplying a filter that specifies the IP addresses, ports, and protocol of interest.

curl -X POST https://api.cloudflare.com/client/v4/accounts/${account_id}/pcaps \
-H 'Content-Type: application/json' \
-H 'X-Auth-Email: [email protected]' \
-H 'X-Auth-Key: 00000000000' \
--data '{
        "filter_v1": {
               "source_address": "1.2.3.4",
               "protocol": 6
        },
        "time_limit": 300,
        "byte_limit": "10mb",
        "packet_limit": 10000,
        "type": "simple",
        "system": "magic-transit"
}'

The filter is applied with nftables, and matching packets are logged via nflog:

table inet pcaps_1 {
    chain pcap_1 {
        ip protocol 6 ip saddr 1.2.3.4 log group 1 comment “packet capture”
    }
}

nflog opens a netfilter socket that carries packet logs from the Linux kernel to user space. There, tcpdump—normally associated with listening on a network interface—is configured to read from the nflog group instead, converting the log stream into a standard packet capture file.

tcpdump -i nflog:1 -w pcap_1.pcap

Delivering the finished file avoids storing sensitive payloads on Cloudflare’s side. Because capture files can be large and contain packet data, they are transferred directly from Cloudflare machines to a customer-chosen cloud storage service, where the customer can manage and retain them.

Availability

On-demand packet captures are now generally available to customers with the Advanced features of Magic Firewall. The current capture API records the first 160 bytes of each packet, with a default sampling rate of 1/100. Full packet captures and dashboard-based control are slated for release in the coming weeks. Customers should contact their account team for updates on timing.