Duplicate IKE packets: find the missing transition

The log shows the same IKE request twice, someone points at the mobile uplink, and the ticket closes with a guess. That guess is the myth: a repeated packet is an observation about one exchange, not a diagnosis of a link. Retransmission is normal behaviour with its own rules, and it appears on healthy paths whenever a reply is slow. Follow the reply before you blame an interface.

The myth: a repeated request proves loss on one link

Two different things produce a duplicate, and neither one names a culprit. The requester can repeat a request because it received no answer, or the capture point can show the same packet twice because of where it is attached to the stack. A tap that sees ingress and egress on the same host will happily log one packet as two, and the operator reading that log has no way to tell the difference without the exchange identifiers. Treat the duplicate as a timer event until you can say which of the two you are holding.

Two uplinks make the confusion worse rather than better. A single log line names one interface, while the reply may have left through the other, so the interface in the message describes where a packet was seen and not the shape of the conversation. That is also why the first question is which exchange you are looking at, not which link is faulty.

What the retransmission actually tells you

In IKEv2, retransmission works like this: the requester repeats a request when no response has arrived, and the responder may resend its cached answer instead of recomputing one. Message identifiers belong to that exchange, which is what makes a repeated request with the same identifier recognisable as the protocol working rather than a fresh attempt. An initial attempt often needs more than a source address or an initiator SPI to correlate, so the platform's own exchange record beats a packet listing. IKEv1 follows different rules with different identifiers, and a vendor warning about a duplicate first packet does not mean the same thing across versions.

So a retransmission timestamp tells you a timer expired. It does not tell you which hop was slow, and it certainly does not tell you the carrier is at fault. Those are separate claims, and only the second one is useful in a ticket.

The practical consequence is to record the exchange before drawing a conclusion. Note the local receiving address, the reply path the policy selected, the peer tuple and the exchange identifiers in one place, because each of those answers a different question when the record is read later.

Four observation points as one chain

Think of the exchange as four links in a chain rather than four separate places to look. A link holds evidence or it stays unknown, and the chain is only as informative as its weakest recorded link. The table below is the inventory: what each position can establish, and what it leaves untouched.

Fill the chain only where you have access, and mark the rest unknown instead of inferring it. A hook that records packets on one machine says nothing about what the far machine received, and a log line noting that a request was seen is not evidence that a reply ever left. Honest gaps are more useful than a complete-looking record built from guesses.

Find the first missing transition

Walk the chain from the initiator outward and stop at the first link with no evidence. If the gateway never logs the request, the fault sits on the path before it. When the gateway logs the same request repeatedly while the client never logs a reply, the return direction is the suspect: source address, translation, and filtering at each boundary you control. If the reply arrives and the client still will not move on, the question has left transport and become policy or state.

Keep the peer and the protocol fixed while you compare, and remember that delay, loss, policy and state each produce a different timeline. A mobile network is not automatically the cause, and a fixed line is not automatically reliable enough for every requirement. Capture both directions while the exchange is live:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

When access stops before the far end, the record still helps if it says where it stops. A capture on the initiator alone can show a request leaving and no reply arriving, which narrows the fault to everything after that hook without pretending to know which hop dropped it. Mark the far links unknown and let the next person with access fill them in. Writing it down that way keeps the record honest and still short.

Compare before you change anything. Repeating the same request against the same peer with the same protocol keeps the variables countable, while a reset, a rekey or a policy edit between captures destroys the comparison. If a change is unavoidable, capture again immediately afterwards so the before and after still describe the same exchange.

What a useful report says

A report worth acting on pairs one request with its reply and names the first step that has no evidence behind it. That sentence survives being read a week later by an engineer who was not there, and it gives the next person a place to start rather than a suspect.

Never weaken identity checks or widen the permitted protocol set just to check a retransmission theory. Save the original packets and event records before any reset, because a reset destroys exactly the material you were about to collect and erases the timing that showed where the exchange stalled.

The myth is that one duplicate proves a carrier is at fault. The reality is that one duplicate proves a timer expired, and the answer lives on the reply path.