Back to all use cases

AssessmentCross-Industry

A VPN fleet upgrade and certificate rotation written down in order before any gateway changes

Network Operations Team

A typical engagement for a network team planning to move a fleet of OpenVPN gateways from 2.5 to 2.7, with a tested high-availability design and an ordered certificate rotation.

Overview

A typical engagement starts with a set of OpenVPN gateways serving staff and site connections, installed over several years on different OpenVPN versions. Some run 2.5, which endoflife.date lists as end of life, certificates are due to expire, and failover has never been tested. The team wants a plan it can run with its own engineers.

Challenge

Each gateway has its own configuration history. Options such as the cipher setting behave differently across 2.6 and 2.7, a revocation list has to reach every gateway, and a certificate rotation done in the wrong order leaves clients rejecting the gateways. High availability is a client profile with several remote entries and has never been exercised under load.

Environment

OpenVPN Community on Linux gateways in two data centers and one cloud account, with an internal CA, client profiles distributed by endpoint management and a load balancer in front of the cloud gateways.

Approach

AceMQ engineers inventory every gateway's version, configuration and certificates, then read the release notes against the options in use. They write the upgrade and rotation order, with trust distributed to clients before any gateway presents a new certificate, and rehearse it on a staging gateway with real client profiles. Failover is tested on a staging pair before the plan relies on it.

Solution

  1. Inventory of OpenVPN versions, configuration files, CA and certificate expiry dates for every gateway
  2. Review of options against current defaults, including moving cipher choices to --data-ciphers where --cipher is still set
  3. Certificate rotation order with trust distributed first, one gateway at a time and a revocation list update on each
  4. Failover design covering client remote lists, retry settings and the load balancer in front of the cloud gateways
  5. Check of data channel offload use per Linux gateway
  6. Staged upgrade plan to 2.7 with a rollback point and a client compatibility check at each step

Outcome

The engagement delivers a written plan the network team can run with its own engineers: the gateway inventory, the ordered upgrade and rotation steps with rollback points, the failover design and its test results from staging, and runbooks for the next rotation.

Technologies

OpenVPNLinuxLoad Balancer
  • Consulting

    PostgreSQL High Availability and Failover Design

    Telecommunications OperatorTelecommunications

    Designing an automated failover architecture with quorum-based leader election, synchronous replication policy, and tested recovery procedures.

    PostgreSQLPatroniKubernetesetcdHAProxy
    Read case study: PostgreSQL High Availability and Failover Design
  • Assessment

    PostgreSQL Performance and Bloat Assessment

    Retail Technology ProviderCross-Industry

    Independent assessment of query performance, index health, table and index bloat, and connection management for a cluster with degrading response times.

    PostgreSQLPgBouncerPrometheusLinux
    Read case study: PostgreSQL Performance and Bloat Assessment
  • Assessment

    Oracle Data Guard Failover Readiness Review

    Regional InsurerCross-Industry

    A typical engagement to find out whether an Oracle Data Guard standby will really take over: transport and apply lag, protection mode, redo sizing, failover runbooks and client reconnection.

    Oracle DatabaseData GuardRMANLinux
    Read case study: Oracle Data Guard Failover Readiness Review
  • Consulting

    Splunk Ingest Volume and Licensing Cost Reduction

    Global Logistics ProviderCross-Industry

    Consulting engagement to reduce Splunk daily ingest volume through filtering, routing, and tiering without losing security or compliance coverage.

    SplunkAmazon S3LinuxKafka
    Read case study: Splunk Ingest Volume and Licensing Cost Reduction
  • Consulting

    Splunk to OpenSearch Saved-Search and Alert Parity Assessment

    Platform Engineering TeamCross-Industry

    A typical engagement for a platform team weighing a move from Splunk to OpenSearch: inventory every saved search, alert and dashboard, and map each one to a replacement before any data moves.

    SplunkOpenSearchKubernetesLinux
    Read case study: Splunk to OpenSearch Saved-Search and Alert Parity Assessment

Related Reading

Ready for an OpenVPN Health Check?

AceMQ's senior OpenVPN engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.