I've been tasked with troubleshooting a persistent site-to-site VPN issue between a Sophos XGS 136 Rev. 2 (running SFOS 20.0.0 GA-Build222) and a third-party firewall. The connection establishes but drops unpredictably, sometimes within minutes, sometimes after a few hours. The logs are consistently pointing to a 'phase1 failure' as the termination cause, but the specifics are frustratingly vague.
I need a systematic approach to debug this that goes beyond the basic connectivity checklist. I've already validated the obvious:
* Pre-shared keys are identical and do not contain special characters.
* Phase 1 and Phase 2 proposals are matched (IKEv2, SHA256, AES-256-GCM, DH group 14).
* Dead Peer Detection is enabled with identical timers on both ends.
* NAT-T is enabled, and we've tried both forcing it on and using auto-detection.
* There are no overlapping IP subnets in the encryption domains.
The core of the problem seems to be that the logs aren't giving me the granular detail needed to see *why* Phase 1 is failing upon rekey or sporadic drop. Is there a specific debug command via CLI or a hidden log viewer that provides more granular IKE SA negotiation details, like which exact packet is failing? The standard WebAdmin log just states the failure, not the cryptographic or payload mismatch.
Here's a sanitized snippet of the recurring log pattern:
```
2024-10-27 08:23:12 [Firewall] notice: ikev2[12345]: IKEv2 CHILD_SA rekey failed (timeout). Initiating re-establishment.
2024-10-27 08:23:42 [Firewall] warning: ikev2[12345]: IKEv2 IKE_SA deleted (phase1 failure).
```
My hypothesis is either a rekey timing mismatch during Phase 1 lifetime or a possible fragmentation/MTU issue that only manifests during certain traffic patterns, causing the IKE SA to corrupt. Before I start packet capturing on the WAN interface (which is messy with ESP traffic), I wanted to query the community on two fronts:
1. What is the definitive method within Sophos XGS to extract the most verbose IKEv2 negotiation logs, including per-payload decodes?
2. Are there known firmware-specific bugs in SFOS 20.0.0 GA-Build222 related to IKEv2 rekey with third-party devices, particularly around GCM cipher suites?
I'm looking for data points, not guesses. If you've solved this, please share the exact diagnostic steps and configuration adjustments that provided stability.
FinOps first, hype last