VPN negotiation, encryption domains, and tunneled traffic
VPN troubleshooting begins by separating establishment of a security association from successful delivery of protected application traffic. A tunnel can be established while routing, selectors, access policy, NAT, or the remote network prevents the intended communication. Conversely, an absent tunnel during an idle period may require a relevant traffic test rather than an immediate restart. Record the peer identities, public endpoints, protected source and destination networks, authentication method, and the exact flow expected to use the VPN.
Analyze negotiation in stages using the actual logs and configuration. IKE establishes the relevant authenticated negotiation and key-management context; IPsec security associations protect the selected traffic. Agreement requires compatible proposals and appropriate identities and credentials. A proposal mismatch, an expired certificate, a wrong shared secret, and an unreachable peer are different problems. A timeout does not uniquely identify which one occurred. Compare both peers' evidence at the same time, and do not reveal secrets in a support ticket or packet-capture annotation.
Distinguish outer and inner traffic. A capture on the external path may show the public peer endpoints and encapsulated traffic rather than the original private application tuple. NAT traversal can change the visible transport, so a filter limited to one expected encapsulation can miss relevant evidence. A working outer exchange does not prove that the inner selectors, route, or application are correct. Where supported, correlate tunnel statistics and inspection-path observations with captures and logs for the actual protected source and destination.
Protected networks and peer expectations must agree with the intended design. Overlapping or incorrectly defined encryption domains can send traffic into the wrong decision path or prevent a matching association. A local route can direct a packet toward an unexpected interface before the intended policy or VPN handling is reached. NAT may alter a tuple that the peer expects if the relevant exemption or translation design is wrong. Verify the actual configured behavior and observed tuples rather than assuming that every VPN requires the same universal NAT rule.
For one-way traffic, investigate the return path, remote policy, remote host, and relevant state instead of treating the local outbound counter as end-to-end proof. For larger transfers that stall, investigate encapsulation overhead and path MTU with appropriate evidence. Rekey-related failures require correlation with lifetime and negotiation events, not a blanket policy change. Clearing associations can disrupt active users and should be targeted and authorized when justified. Finish by checking the protected application in both directions and documenting any remaining limitations; a green tunnel indicator alone is not a complete acceptance test.