Remote Packet Capture: Keep the Sensor Local, the Analyst Remote

Packet capture belongs where the packets already flow, and the remote analyst rarely sits there. The workable arrangement is a sensor on the observed segment plus a VPN that carries administration and retrieval, not the whole mirrored link. That split keeps the analyst's laptop out of the capture path and keeps sensitive payloads on site. The steps below choose the interface, bound the file and move only what the question needs.

A remote laptop is not a tap

Joining the network over VPN gives your machine a route to the sensor, not visibility into traffic between other hosts. A capture taken on your laptop sees only packets delivered to your laptop's interface. Watching a switched link requires the network owner to provide a mirror or tap feeding a sensor on site. Even then the mirror has limits, because oversubscribed destinations drop frames and a gateway never sees traffic that stays inside the same VLAN.

An encrypted stream also stays encrypted at the sensor, since the TLS payload belongs to the endpoints. Capture yields headers, timing and volume, not plaintext.

Pick the interface that can see the flow

Before filtering anything, list the interfaces and confirm which one carries the path you were asked about. Guessing between a physical port, a bond and a bridge is a common way to collect an empty file.

ip -br link
dumpcap -D

Match the interface name to the observation point in the change record, not to a name you remember from another host. If the packet count stays at zero while the service is visibly busy, the sensor sits on the wrong segment or the mirror is configured for the other direction. Prove the path with a known exchange first, so a broken mirror is not mistaken for a quiet application. Write the interface and mirror details into the capture notes while they are still fresh.

Bound the capture with a filter and a ring

A capture without bounds fills the disk and collects more than the question requires. Put the permitted source, destination and protocol into the filter, then cap the file size and the number of files.

tcpdump -i eth0 -n -s 128 -c 5000 -W 4 -C 25 -w /var/tmp/cap.pcap 'host 203.0.113.10 and tcp port 443'

The address and port above are examples from the documentation range, so substitute the approved values and keep the window short enough that the evidence survives the ring. The snapshot length truncates payload while keeping headers, which is usually enough for a connectivity question and far easier to store. Read the kernel drop line that tcpdump prints on exit, because a high drop count means the capture is incomplete rather than quiet. Preserve the window you need before the ring overwrites it, and record the filter string next to the file name.

Move the file, not the whole link

Retrieve the finished capture over the management channel instead of streaming the mirror across the WAN. One transfer is easier to authorize, log and delete than a continuous export.

scp [email protected]:/var/tmp/cap.pcap ./

Keep the file readable only by the operator account, and delete it from the sensor once the analysis copy is verified. If live export genuinely is the requirement, size the mirror encapsulation and the transport together, because the overhead can exceed the link budget. Record the visibility gaps either way, since a capture is evidence with a known observation point rather than a complete record of the network.