DPD replies prove the IKE peer is alive, not that your data flows
Liveness replies, a padding notification and narrowed selectors describe three different things. Read them separately before blaming one for a stall.
IPsec logs can show liveness replies while the application in front of them stalls, and both facts can be true at once. A DPD response establishes that the peer's IKE processing answered at that moment; it says nothing about whether the child SA carries the packet you care about. Treating every warning near an outage as its cause is how a selector problem gets diagnosed as a protocol bug. Three observations get confused most often, and they answer three different questions. Read them by association and purpose before you read them by timestamp.
What each observation proves
The table separates what each observation establishes from what it merely accompanies.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
None of the three is an error by itself. Each becomes interesting only next to the flow you are debugging, and a row that cannot be tied to a specific flow is context rather than evidence.
Liveness is not data health
DPD runs as an INFORMATIONAL exchange, a control-plane conversation between IKE daemons. A reply proves the peer's IKE process is reachable and willing to answer, and a timeout proves that it is not. Neither result exercises the child SA, the selectors, the forwarding path or the application's reply, so healthy DPD alongside a stalled transfer is a coherent picture rather than a contradiction.
That is why the liveness lines are the least useful part of a data-plane ticket, however reassuring they look at the top of the log.
The padding notification is a statement about padding
TFC padding is the most over-read line in these logs. It says that traffic-flow-confidentiality padding will not be accepted for that child SA, which is a statement about an optional padding feature rather than a rejection of ESP protection. Finding it near a failure is usually a coincidence of verbosity, and toggling padding changes nothing about selector coverage.
The IKEv2 specification defines both the notification and the selector negotiation, and an implementation's warning label does not replace the protocol meaning in either case.
Narrowing is quieter and more likely to matter
A responder may accept a subset of the offered selectors, and the accepted set can be printed across several entries, one port-qualified and another covering all ports. Reading only the first port-qualified line understates what was accepted; reading only the broad line overstates it. Compare the printed proposal with the installed policy, because the proposal is what the peers said and the policy is what the kernel will match. When they disagree, the tunnel exists and the traffic does not, which is the classic intermittent complaint. Reverse the local and remote perspective when comparing peers, since each side's local is the other's remote.
Host-specific entries with a port restriction are worth reading twice, because they are the ones that exclude ICMP or a second port while leaving a ping to the gateway working.
Build one record for the failing flow
Record source, destination, address family, protocol and port as seen at the protection decision, including any deliberate translation. Those are the values that must match a selector, and they are also the values people retype from memory when the ticket reaches a third pair of hands.
Then identify the child SA and its directional counters: swanctl --list-sas gives the association summary on a strongSwan host, and ip -s xfrm state gives the counters. Read them after a fresh permitted request rather than while the system is idle. No outbound increase points at selection or the local path; outbound without a corresponding inbound points at the peer, its forwarding or its replies.
A completed application exchange outranks either counter, which is why the test should end at the application rather than at the tunnel indicator.
Choose the correction afterwards
Only after that record exists is there a correction to choose: accepted selectors, route, filtering, peer implementation, or a boundary you have now demonstrated. Resetting the peer changes several states at once and often restores traffic without explaining which one was wrong, so the outage returns. Keep kernel state dumps out of tickets too, since they can contain keys and the narrow summary is enough for anyone who needs to help.
When the record contradicts your first theory, believe the record and rewrite the theory; that habit is worth more than any single log line discussed here.