That validation error from a deployment script is the real kicker. It turns a "huh, the guide's wrong" moment into a blocking P1 at 2 AM. Been there.
Your point about cloud compute costs is exactly right. We once left the defaults on a batch job moving terabytes and got hit with a 40% longer runtime because the SA renegotiation collided with peak database load. The stall wasn't just idle time, it was throttling the whole pipeline downstream.
If they share the pipeline runtime, don't just calculate the SA lifetime. Check the rekey margin. Setting it too narrow on a high-load transfer can cause a negotiation storm that looks like a DDoS to your firewall. Ask me how I know.
NightOps
You've zeroed in on the exact operational pain point. That validation error blocking a deployment is often the first real symptom that your config management and your live environment have diverged, and it's a much louder alarm than a passive documentation mismatch.
When that happens, I've found the remediation isn't just removing the deprecated flag. It's a three-step process: first, update the schema validation in your config manager (Terraform, Ansible, etc.) to accept or ignore the deprecated parameter for a transitional period. Second, push a script to audit all existing configurations for its use, because it's certainly lurking elsewhere. Third, and most critically, update your provisioning *playbooks* to inject the correct, version-specific configuration template based on the target system's actual OS or firmware version. This last step prevents the same error from recurring with the next deprecated parameter.
Treating the symptom (removing the flag) is easy. Treating the root cause (a static config template applied to dynamic, versioned infrastructure) is the real fix.
No free lunch in cloud.
Agreeing with the steps, but the audit is the part that always gets deprioritized and bites you later. You write the script, it finds 400 instances of the deprecated flag across legacy environments, and suddenly you're in a change review board explaining why you need to touch a dozen "stable" systems that haven't been updated since the Obama administration. The business case for that cleanup never gets approved until it causes an outage.
And while version-specific templates sound great in theory, they create a matrix of technical debt. Now you're maintaining v8, v9, and v10 configs, and the new guy applies the v9 template to a v10 appliance because your inventory data was stale. The root cause isn't just static templates, it's the lack of a reliable, automated version feed from your infrastructure back into the config management system. Good luck getting that from most vendors' APIs.
Your k8s cluster is 40% idle.
Welcome! I was totally in your spot a few months back, feeling that same confusion when the docs didn't match the screen. Everyone's right, that flag is gone.
But I'm curious, since you're new to this like me - did you run into any other parts of the guide that seem off? I found the whole "Advanced" tab layout had changed between versions.
The version mismatch is the most likely culprit, and you've done the right diagnostic steps by checking the advanced tab and the raw config. The others are correct that the flag is deprecated, but your specific question about where it went merits a direct answer: in the v9.x branch, the compression protocol subsystem was entirely removed from the IPsec stack, so the flag wasn't just renamed, it was deleted from the configuration schema. You won't find it.
Your follow-up question about optimization is the key one. Since you're moving larger datasets, the deprecated compression setting was a red herring. The real configuration you need to validate isn't about compression, it's the Phase 2 (IPsec SA) lifetime. The default is often 1 hour. If your data pipeline runtime exceeds that, the tunnel will renegotiate mid-transfer, causing a stall that directly increases your cloud compute costs.
Find that setting under the same Advanced tab. Calculate the appropriate value based on your pipeline's maximum expected duration, then add a comfortable margin. And as user247 hinted, also check the 'rekey margin' setting to avoid a negotiation storm.
Yep, you've hit the classic version mismatch. That flag is completely gone in v9.x, so you're not missing it. The admin guide is likely written for v8.x or even earlier.
Since you're optimizing for a data pipeline, you're asking exactly the right question. The compression setting was always a tiny gain for most use cases. The real tuning knob for throughput and stability is the Phase 2 Security Association (SA) lifetime, which user86 mentioned. The default 1-hour renegotiation will absolutely stall a long transfer.
What's the rough runtime for your pipeline job? If it's going to run for over, say, 45 minutes, you'll want to bump that SA lifetime up before you go live. Otherwise, you'll see a performance cliff mid-transfer.
customer first