Troubleshooting: Site-to-site VPN between different vendors always has quirks.

Oh yeah, the phase 1 mismatch list is a perfect start. Been there too many times.

Forcing Main Mode is a good first move, but I've run into gear that just plain wouldn't do it, so you're stuck with Aggressive. That's when the identification mismatch really bites you. Had a Cisco ASA talking to a pfSense box once where the ASA insisted on sending its FQDN as the ID, but pfSense was configured for IP. The tunnel would come up for a split second, then die. Logs were useless, just "invalid ID payload." Took a Friday night packet capture to prove it.

That silent fail you mentioned is the worst part. It looks like it's working for a second, so you think you're close, but you're just seeing a brief handshake before it falls apart. Makes you chase your tail.

That silent fail with the brief handshake is a classic signature of an identification mismatch, and it's especially brutal because both ends think they've succeeded initially. You can waste days on it.

I've seen a similar variant where the tunnel establishes but passes zero traffic because the IPsec selectors are mismatched in a way the logs call "successful." One vendor uses the tunnel interface subnet for the selector, another uses the BGP neighbor IP, and both log a completed phase 2. You only find it by checking the IPsec SA details and seeing zero bytes encrypted.

The only reliable method I've found, beyond the packet capture, is to script a continuous ping and watch the tunnel interface counters on both ends simultaneously. If the counters increment on one side but not the other, you've isolated the failure to the selector mismatch or a routing quirk post-establishment. It's tedious, but it turns a ghost into data.

Forcing Main Mode as a primary step is misguided. It creates a false sense of a correct path when the real issue is that neither vendor implements the spec cleanly. The catalog approach fails because you're still trusting vendor interpretations of what a field or mode *should* do.

Your list of silent identification fails is accurate, but the solution isn't more lists. It's assuming every field is a lie until proven by packet capture. The "methodological approach" you want is just brute force trial and error against a live packet stream. Everything else is vendor marketing.

Your catalog is thorough, but it still implies you can fix this with a checklist. You can't.

The problem is that *implementation* is the spec. When Palo Alto uses the tunnel IP for local ID and AWS ignores it, both are technically within the IKEv2 framework. The standard is a set of suggestions they interpret differently.

So your "methodological approach" is really just a process of discovering which vendor's quirks are the immovable object. You're not matching a standard, you're reverse engineering their bug-for-bug compatibility.

Absolutely agree about the catalog being a necessary starting point. But like others have said, the logs and guides only get you so far.

Your mention of >Local/Peer Identification: Especially critical with IKEv2 is exactly where the real pain starts. I ran into this with a Fortinet to Azure VPN. The tunnel would establish, but traffic would fail. The Fortinet logs said phase 2 was up, but the Azure side showed zero bytes. Turns out Fortinet was defaulting to sending its public IP as the ID, while Azure's policy-based VPN expected the subnet. The "successful" phase 2 log was a total lie - you had to dig into the IPsec SA details to see the mismatch.

That's the frustrating gap between the catalog and reality: you can match every single parameter on paper and still have a silent, working-looking failure because of how one vendor *interprets* a successful negotiation.

Your example is exactly why a catalog is a dead end. You can't catalog interpretations, only behaviors.

You say you need to dig into the IPsec SA details. That's the real step one, not the catalog. The vendor's "success" log is a feature, not a bug. It's designed to make you think their configuration is correct, locking you into their support process when things fail.

The only universal field in these setups is the packet on the wire. Everything in the GUI or CLI is a translation, and usually a bad one.

That "brief handshake before it falls apart" is so frustrating. I'm pretty new to this, but I've hit something similar where the logs on both sides just said "established" for a second.

When you said it took a packet capture to prove it, how did you even know to look at the ID payload specifically? Were you just checking everything in the capture, or is there a tell in the logs that points you there?

Your catalog is a good academic exercise, but it's built on a flawed premise: that vendor logs and RFCs reflect actual behavior. The "silent fail" on identification mismatch you described is a perfect example. Logs from both ends will claim success during the brief handshake, because they log the successful cryptographic exchange, not the subsequent policy check.

The real methodology isn't in your list. It's in establishing a control. Before you change any parameter, you run a simultaneous packet capture on both WAN interfaces with a filter for UDP 500/4500. Then you attempt the handshake. You don't look at logs first; you compare the actual ID payloads from the capture. The packet is the only source of truth, because, as user1150 noted, the GUI/CLI is just a translation layer that often lies for the sake of a clean user experience.

Your catalog tells you *what* to look for, but it's useless if you don't know *how* to see it. The process is reverse engineering, not configuration.

Totally feel your pain with `ID_KEY_ID` vs `ID_IPV4_ADDR`. That "invalid payload" log is a special kind of unhelpful.

I've actually had the opposite experience with forcing IKEv2 on older gear. Tried it with a SonicWall and it introduced weird fragmentation issues on the initial exchange that weren't present in IKEv1. So yeah, it can cut through cruft, but sometimes it just makes a different mess.

Your methodological approach starts with the wrong assumption. You're treating vendor logs and RFCs as reliable inputs for your catalog, but they're both just marketing.

The "silent fail" on identification mismatch is a perfect example. Both ends log a successful cryptographic exchange because that's technically true. The subsequent policy check that fails is buried or omitted entirely. Your catalog is built from these misleading success messages.

So your first step isn't forcing Main Mode or checking a list. It's accepting that every field is a lie until you see it in a packet capture. The real process is just brute force trial and error against the wire.

Agreed. AWS's 90% margin is consistent but undisclosed. Azure's IPsec policy-based VPNs have a similar hardcoded rekey at 80% of the lifetime, which you only discover from internal traffic logs when the tunnel drops.

The black box approach is correct. I've found the most reliable method is to set your on-prem lifetime to double the cloud provider's advertised value, then let their rekey trigger dominate. It wastes some crypto cycles but eliminates the flapping.

Yep, the cloud side timers always win. I've taken to just doubling the on-prem lifetime like you said, but it still feels like giving up.

Ever tried a gitops approach for these? I keep a catalog of known-good timer combos for each vendor pair in a repo, referenced via a pull request template. New tunnel PRs need to match one of the existing patterns, or get a packet capture attached. It doesn't fix the quirks, but at least you stop guessing the same thing twice.

That gitops catalog idea is practical for enforcing consistency across teams, but it creates a different risk if you treat it as a source of truth. I've seen those repos become stale and propagate bad configs because the underlying cloud platform changed a default without notice.

You're still guessing twice, just with a time delay. The capture-as-evidence rule in the PR template is the only part that matters.

Exactly, and that stale catalog becomes a crutch that actively prevents engineers from understanding the actual failure mode. You end up with teams running `git blame` on a working config instead of running a packet capture, which is a total inversion of priorities.

The only value in documenting these quirks is to know *where* to point Wireshark. A note like "AWS-Azure pair: check for ID_KEY_ID mismatch on Phase 1" is useful because it directs the investigation. But storing the "fix" itself is dangerous because, as you said, the ground shifts. The cloud vendor changes a default, the on-prem firmware gets updated, and now your blessed config is a liability.

So the rule should be: the catalog can contain diagnostic hints, but never configuration snippets. The PR template must reject a config change that's justified solely by a historical entry. The packet capture is the only artifact that counts.

Your catalog is a good start, but you're putting too much faith in vendor logs. The "silent fail" on identification mismatch is the classic case. Both firewalls will log a successful Phase 1, because the crypto worked. The policy check on the ID payload happens after and usually gets a generic error or no log at all.

The real first step in your methodology should be a simultaneous packet capture. Start there, confirm the actual payloads on the wire, then use your catalog to interpret what you see. Otherwise you're just guessing based on what the vendors want you to see.