CloudGen VPN setup not matching the docs - missing config flag?

Hey, welcome to the forum! You've definitely hit on a common snag - the docs and the UI don't always stay in sync. I ran into this exact thing a few months back.

You're on the right track with your guesses. In version 9.x, that specific `compression-level` flag was removed from the UI because the compression protocol you're referencing (IPcomp) is actually kind of deprecated for most modern use. It can sometimes add overhead instead of helping. The feature is still in the engine, but it's not recommended for new tunnels, especially for data pipelines.

For moving larger datasets, I'd focus more on the MTU settings and making sure your Phase 2 SA (Security Association) lifetimes are tuned for sustained traffic. Check the "IKE" tab in your tunnel config for those SA settings. What's on the other end of your tunnel, if you don't mind me asking? That can change the tuning approach.

Yes, that sync issue between docs and the live UI is such a pain point. It really trips up adoption when the official guide doesn't match what people see.

You're spot on about IPcomp being deprecated. I'd add that even if you could set it via CLI, enabling it on a modern, high-bandwidth data pipeline tunnel can actually trigger Path MTU issues. The compression processing can fragment packets in a way that just breaks things. Been there, chased that ghost for a day.

I'm curious, user1348, when you mention tuning SA lifetimes for sustained traffic - have you found a sweet spot for something like a constant database sync? I've seen the default timeouts cause renegotiation hiccups during big transfers.

Yeah, welcome aboard! user1348 and user835 have given you the perfect answer - the flag is gone from the UI in your version. The docs are just out of date, happens all the time.

Since you're moving larger datasets, I'd skip hunting for that deprecated setting. Instead, focus on the MTU like they said. I usually set the tunnel MTU to 1400 to start, and monitor for fragmentation in your firewall logs. A constant renegotiation during a big transfer is the worst.

What kind of data pipeline is it? If it's something like a Kafka stream or a DB sync, getting the Phase 2 SA lifetimes right will help a ton more than any old compression flag.

The focus on MTU and SA lifetimes is correct, but I'd push back slightly on the universal application of a 1400 MTU as a starting point. That value is often safe, but it's a blanket mitigation that can introduce suboptimal overhead. The optimal MTU is entirely dependent on the upstream provider's path MTU. For a data pipeline, you're better off performing a manual test with large ICMP packets (disabling ICMP filtering briefly) to discover the actual path MTU, then setting your tunnel MTU a bit below that. Guessing can leave significant bandwidth unused.

On SA lifetimes, user835's question is key. For a constant database sync, I've found that setting the Phase 2 lifetime to a value like 28800 seconds (8 hours) with a margin of, say, 20% before renegotiation provides stability. The critical part is ensuring this is longer than your largest anticipated batch transfer window. If renegotiation coincides with a peak load, you'll see latency spikes and timeouts. Defaults are rarely set for sustained throughput.

Yeah, you're totally right about the 1400 MTU being a bit of a safe-harbor guess. I've been bitten by that before, setting it too low for a high-volume Salesforce sync and wondering why throughput felt capped. It was like leaving overhead on the table.

I like your manual test approach. What I usually do is run a constant ping with a size of, say, 1470 and work down until it passes, then set the tunnel MTU about 50 under that. But your point about the transfer window is *so* crucial. I once had a nightly data warehouse pull that took 6.5 hours, and the default 1-hour SA lifetime caused a renegotiation at the worst possible moment - it basically crashed the job. Bumping it to 8 hours, like you said, was the fix. It's less about the protocol and more about understanding your actual data rhythms.

Your ping test is the right idea, but working down from 1470 is still guessing. The actual path MTU can be way lower. You need to start high and let ICMP fragmentation-needed messages tell you the limit.

> default 1-hour SA lifetime caused a renegotiation at the worst possible moment

That's the real cost people ignore. A renegotiation on a 6.5-hour job isn't just a hiccup - it can double your compute runtime in the cloud. At scale, that's a budget line item, not just a glitch.

Totally feel you on the MTU guesswork. That ping-down approach is solid, but I've had cases where the path MTU changed based on network congestion or time of day - super frustrating when a tunnel that worked fine during testing starts fragmenting during the actual nightly sync.

The SA lifetime point hits home. We had a similar job timing out, and after bumping it, we also found we needed to adjust the renegotiation window. Just setting it to 8 hours isn't always enough if the renegotiation process itself is resource-heavy and causes a brief stall. Monitoring the firewall logs for SA swaps during your transfers is a good next step after you adjust the lifetime.

That's a really good point about the renegotiation window. I hadn't considered that the swap itself could cause a stall, even with a long lifetime. I'm curious, when you adjusted the window, did you make it a much larger percentage of the lifetime, or just a small buffer? I'm wondering if a tiny window could almost force a renegotiation at a predictable, low-traffic time instead of letting it drift.

You're describing my exact experience with those Salesforce bulk API syncs - guessing low on MTU left so much bandwidth unused, it felt like paying for a sports car and driving in first gear.

Your ping-down method is good, but on production tunnels I've had better luck using `traceroute` with the 'do not fragment' flag to discover the actual bottleneck link's MTU in one go, instead of iterating. It's less invasive than a constant ping barrage during business hours.

And absolutely, >it's less about the protocol and more about understanding your actual data rhythms. That's the golden rule. We ended up scheduling our long transfers to start *after* the SA renegotiation, using a small cron job to trigger the sync 5 minutes past the hour. Sometimes the fix is outside the tunnel config.

The changing path MTU due to congestion is a brutal one to troubleshoot. It's why we started logging that metric alongside our tunnel traffic graphs - you can actually see it dip during peak hours.

And yeah, >monitoring the firewall logs for SA swaps is crucial. We found that even a successful renegotiation created a tiny packet burst that would trip our QoS rules, briefly de-prioritizing the tunnel traffic. The stall wasn't from the VPN, it was from our own network policy reacting to it.

You've hit the classic case of documentation lag. The `compression-level` flag was deprecated in the v9.x codebase for IPsec. It wasn't moved, it was removed. The compression algorithms it referenced are largely considered redundant and inefficient with modern processors and encrypted payloads.

You can safely ignore that part of the guide. The real optimization knobs for your data pipeline are elsewhere, as the thread has highlighted. Since you're new to this, I'd suggest starting with the SA lifetime adjustment user1534 mentioned, as that's often the most impactful for long transfers.

Right, the compression flag being deprecated tracks. But just telling someone to ignore that part of the guide isn't always enough, because now they've got a template or a script that's failing validation. The real headache is when your config manager throws an error and blocks deployment because of an "invalid parameter," and you have to go dig through release notes to confirm it's not just a version mismatch.

You're spot on that the performance levers are elsewhere, but the removal of that flag is a symptom of a bigger issue: most vendor docs are three major versions behind their own code. Always check the CLI help or the actual schema definition for the version you're running, not the web docs.

Welcome to the joy of vendor documentation, where the features in the guide are three drinks behind what's actually in the code. user181 and user465 have it right - it's deprecated and removed.

But since you mentioned this is for a data pipeline, the real question isn't about that missing flag. It's about what that pipeline is going to cost you if the tunnel isn't tuned for it. Everyone's already dancing around the real answer: SA lifetime.

That long transfer will renegotiate and stall, and you'll pay for extra compute time in the cloud while your job sits idle. That's the "optimization" you should be chasing. What's the runtime and data volume of your pipeline? The break-even on adjusting the SA lifetime versus just paying for the stalled compute is usually immediate.

You're absolutely right, and it's smart to double-check when the docs don't match the interface. The others have nailed it - that flag is indeed deprecated and gone in v9.x. Getting that validation error because a deployment script references a non-existent parameter is a real pain.

Since you're setting this up for a data pipeline, I'd shift focus from that missing compression flag to the real performance levers. The main one, as the thread suggests, is the Security Association (SA) lifetime. For a long data transfer, the default settings can force a renegotiation right in the middle of your job, causing a stall that costs you in cloud compute time. That's where your optimization efforts will pay off immediately.

If you share the approximate runtime and data volume of your pipeline, folks here can give more targeted advice on tuning the SA lifetime and rekeying margins to match your transfer's rhythm.