Label the Mode Before Comparing Two VPN Packet Diagrams
Two VPN packet diagrams can disagree and both be right. State the mode, the channel, the outer transport and the payload before comparing any headers.
Two diagrams can both be correct and look different, because they may describe different packets. A negotiation message and an application-data packet do not share a layout, even inside one session, and neither do transport mode and tunnel mode. Comparing drawings without stating which packet and which mode each represents produces an argument about headers that were never supposed to match. Four labels settle it before the comparison starts.
Write the implementation and mode, the channel, the outer transport and the carried payload beside each drawing.
Transport Mode and Tunnel Mode Move the Header Differently
In transport mode, ESP sits after the IP header and before the carried protocol, so the original IP header stays outside the protection. In tunnel mode, a new outer IP header addresses the two IPsec peers and the protected inner packet keeps its own IP header. Both are defined by RFC 4303 and both are correct for their mode. A simplified sketch that omits the trailer and integrity fields is fine for placement and useless for byte counting.
Transport does not mean TCP or UDP specifically. The carried next-layer protocol can be anything, and a diagram equating transport mode with one protocol has quietly added an assumption.
Control Messages Are Not Data Messages
L2TP keeps two message types apart: data messages carrying PPP frames, and control messages that set up, maintain and tear down the tunnel and its calls. The control channel is reliable, whereas lost data messages are simply not retransmitted by L2TP. A drawing containing PPP may therefore describe the payload a data message carries, not a header every protected session must include. Combining L2TP with protection adds the chosen security arrangement on top and does not make every message identical.
If a diagram claims both kinds of message look the same, it is describing a different protocol or a different scope.
Compare Equivalent Capture Points
An outer-interface capture shows the protection and transport headers; an inner capture, taken after decapsulation, shows the carried packet. Neither is wrong, and comparing one against the other makes headers look missing or duplicated. UDP encapsulation, as defined for NAT traversal, adds another outer layer that a native-ESP drawing will not have. Both drawings can be valid descriptions of different transport arrangements.
State the capture point with the diagram, and compare equivalent messages in equivalent modes. A missing header is only evidence of a fault when both drawings claim the same point and the same packet type.
Keep the Labels With the Drawing
A diagram without labels ages badly, because the next reader supplies their own assumptions. Add the four labels, mark the protection boundary, and note whether the drawing is for placement or for sizing. If it is for sizing, use the complete specification rather than a sketch. The cost of the labels is a minute; the cost of the argument they prevent is an afternoon.
When two documents disagree, compare their labels first. Disagreement at the mode or channel level explains the difference completely, and no header is actually missing.
Record which packet, which mode and which capture point the drawing shows. That record is the diagram's other half.