Promiscuous Mode on a VPN Adapter Kills the Connection
A capture on a tunnel adapter can stop it forwarding. Clear promiscuous mode, pick the layer that answers the question, and treat the file as a secret.
Wireshark behaves perfectly on an Ethernet interface and then, on a VPN adapter, the tunnel stops passing traffic the moment the capture starts. The capture window keeps filling, so the tool looks healthy while the connection underneath it dies. Promiscuous mode is the usual cause, because a tunnel driver asked for every frame on a segment it does not have can end up in a state where nothing leaves.
Clear that option first, then decide which layer you actually need to see.
Two adapters, two different views
A VPN client usually presents two interfaces: the physical one that carries the encrypted transport, and a virtual one that carries the decrypted inner traffic. They answer different questions. The physical capture shows endpoints, ports and packet sizes, while the virtual one shows the application protocols as the tunnel delivers them. Picking one without knowing which question you are asking wastes the capture.
Neither view is a superset of the other, and one capture rarely answers both questions at once.
Choose the interface from the question rather than from the list order, because a PPP-style client can present its adapter as an Ethernet device and the display name will not tell you which layer you selected. A capture on a gateway or a mirror port adds a third view, showing the path after forwarding, which is where asymmetric routing and filtering become visible.
| Capture point | What it shows | What it cannot show |
|---|---|---|
| Physical interface | Outer endpoints, ports, packet sizes | Any inner payload |
| Tunnel interface | Decrypted inner traffic | What the VPN added around it |
| Gateway or mirror | Forwarded path after the tunnel | The client's own decision process |
Why promiscuous mode breaks a tunnel adapter
Promiscuous mode asks the driver to deliver frames not addressed to the host, which makes sense on a shared Ethernet segment and very little sense on a point-to-point tunnel. Some drivers handle the request gracefully; others stop dequeuing transmit traffic, and the interface silently becomes a black hole. The capture still records what arrives, so the file looks like evidence of a working link. That gap between what the file shows and what the interface did is the whole trap.
Turn the option off before the first packet, keep the capture filter narrow, and use a small buffer. A large ring buffer on a busy interface drops precisely the frames that mattered, which produces a capture that is complete everywhere except where the fault was.
Should the link stall mid-capture, halt it and watch for recovery. That single observation separates a capture side effect from a genuine tunnel fault, and it takes less time than any amount of filter tuning.
Making an IPsec capture readable
An IPsec capture on its own is not readable, because ESP encrypts the payload. Wireshark can decode it when you supply the session keys, or when it can follow the IKE negotiation that produced them, which means the handshake has to be in the same file.
Keys expire. After the peers rekey, a set of old keys stops working partway through the capture, and the result looks like a decoder bug rather than a time boundary.
Follow the vendor's documented key format rather than importing material from an unrelated source, and expect some platforms to refuse the workflow entirely. When the gateway will not hand over keys or permit the capture, accept that the payload is not inspectable from where you sit. Endpoint logs and interface counters are the remaining evidence, and they are usually enough for a routing question.
A capture you can share safely
An inner capture is closer to a credential dump than to a log. It can contain names, addresses and plaintext from protocols written on the assumption that nobody would ever read them, which makes the file itself the sensitive artefact rather than the analysis.
Make sure the host and network are ones you may capture on, note down both the interface and the filter with the result, limit the session to the few minutes that answer the question, and remove the file once you are done. If it has to be shared, describe the flow or strip the payload first.
Then repeat the original user task. A capture proving a packet arrived is not proof that the application accepted the answer, and the difference between those two is usually where the real fault lives.