We enabled the memory boundary check feature in Absolute Secure Access last week. Since then, our user help desk is flooded with timeout complaints, especially for users accessing high-memory applications through the tunnel.
Our config is standard. The timeout threshold is at the default 30 seconds. Support pointed to our network latency, but the issue started exactly with the feature toggle. Has anyone found a stable configuration with this check enabled, or is rolling it back the only viable fix?
That's rough. We got hit by the same thing during our trial. Support gave us the network latency line too, but our logs showed the checks themselves adding 8-10 seconds per handshake for some finance apps.
Did you try raising the timeout threshold way up, just as a test? We set it to 120 seconds as a diagnostic step and the timeouts stopped immediately. It proved the feature was the cause, not our network. We're still trying to find a permanent middle ground, though.
Is your default 30 seconds for the boundary check, or is that the tunnel's general timeout setting?
Raising the timeout to 120 seconds is a good diagnostic, but it just papers over the problem. An 8-10 second delay per handshake means the memory check is performing a full, sequential scan on sizable chunks of data. That's not a network issue, it's a bad algorithm.
It proves the feature isn't production-ready for anything handling actual application traffic. The "middle ground" you're looking for probably doesn't exist without them fixing the scan logic. Have you checked if the delay scales linearly with the size of the memory regions being audited? That would confirm the design flaw.
And to your question, the 30 seconds is almost certainly the tunnel's general idle timeout. The boundary check delay would be eating directly into that.
That's a classic support deflection, isn't it? "It's your network." The correlation is too perfect to ignore. Rolling it back is the only viable fix for now, honestly. The feature's performance impact on high-memory apps is the root cause, so no stable config exists until they optimize the scan. We had to revert too.
It's not just a performance issue, it's a contractual one. Rolling back might be your only fix, but you should check what your support SLA says about "feature readiness." If this was a headline capability you bought, them telling you to disable it because it's unusable should trigger a credits discussion.
But, the cynical part of me wonders if "rolling back is the only viable fix" is exactly what they want. They can now claim the feature exists, while the default advice from the field is to keep it turned off. A checkbox feature.
— skeptical but fair
Oof, that sounds rough and way too familiar. It's almost definitely the new check causing the lag.
>Has anyone found a stable configuration with this check enabled
Have you tried adjusting the audit depth or sampling rate, if those settings are exposed? Sometimes you can dial down how thorough the check is, trading some security for performance. It might get you under the 30-second timeout threshold.
But honestly, if your config is standard and you're seeing instant timeouts, rolling back might be your only real option until they patch it.
CloudNewbie