How we connected a client’s cloud-hosted server to three separate third-party networks through a single, hardened gateway — encrypted, redundant, and compliant.
Overview
As organisations increasingly rely on cloud-hosted infrastructure to run critical operations, the need to connect that infrastructure securely to external partners has become a fundamental requirement — not an afterthought. This case study documents the design and deployment of a multi-vendor site-to-site VPN solution on Oracle Cloud Infrastructure (OCI), carried out on behalf of a client operating in a regulated industry. The client required their cloud-hosted server to communicate with three separate third-party networks over dedicated, encrypted tunnels — with no exposure to the public internet, no single point of failure, and a clear path to onboarding additional vendors in future. This document outlines the approach taken, the reasoning behind key decisions, and the outcome delivered.
The Challenge
- The client’s server, hosted on Oracle Cloud Infrastructure (OCI), needed secure, encrypted connectivity to three separate third-party networks — each operating their own independent infrastructure.
- Compliance requirements mandated that all inter-party data exchange occur over dedicated, authenticated, encrypted channels. The public internet was not an option.
- Each of the three vendors had distinct network endpoints, requiring independent tunnel configurations — all managed through a single, centralised cloud gateway.
- The solution needed to be redundant and production-grade. A tunnel failure could not be allowed to interrupt live operations.
Architecture Overview
We configured a centralized gateway architecture using OCI’s Dynamic Routing Gateway (DRG) as the single routing hub. All three vendor tunnels terminate at this DRG, which connects via a single VCN attachment directly to the client’s server. This approach keeps the architecture clean, auditable, and easy to scale.
| Component | Vendor 1 | Vendor 2 | Vendor 3 |
|---|---|---|---|
|
Network |
Third-party network A |
Third-party network B |
Third-party network C |
|
CPE |
Dedicated CPE |
Dedicated CPE |
Dedicated CPE |
|
Routing |
Static |
Static |
Static |
|
Tunnels |
2 (IKEv2) |
2 (IKEv2) |
2 (IKEv2) |
All three connections terminate at a single Dynamic Routing Gateway, which attaches to the client’s Virtual Cloud Network (VCN). Route rules direct outbound traffic to each vendor through its designated tunnel only — fully isolated per connection.
Why This Approach
The client’s server infrastructure resides within a single, dedicated Virtual Cloud Network (VCN). The Dynamic Routing Gateway (DRG) configured for this VCN was used as a centralized routing hub. Adding further vendors in future requires only a new CPE and VPN configuration, not a full infrastructure rebuild. Static routing was chosen over dynamic routing (BGP) because each vendor’s network range is fixed and well-defined. This keeps the configuration simple, deterministic, and significantly easier to troubleshoot under pressure. That said, this is not a one-size-fits-all decision — the routing approach, tunnel settings, and overall topology are fully adjustable based on each client’s requirements. For environments where network ranges change frequently or where automatic failover between routes is needed, BGP can be configured instead.
Vendor Coordination
A site-to-site VPN requires both sides of the tunnel to be configured with identical settings — mismatched parameters on either end will prevent the tunnel from establishing. Because of this, successful deployment depends on close coordination with each third-party vendor before any configuration is applied.
In this engagement, each vendor provided the following information ahead of configuration:
- Their public IP address (used to define the Customer-Premises Equipment on the OCI side)
- Their local network IP range (used to configure static routes and traffic selectors)
- Preferred IKE version and any specific Phase 1 / Phase 2 parameters they required
- Any firewall or security rules their side needed to permit the connection
The importance of having the right technical information from all parties at the right time is vital. When dealing with complex network configurations, securing accurate information upfront is the single most critical factor to prevent project delays, streamline troubleshooting, and accelerate the onboarding process.
Once the OCI side was fully staged with this information, the vendors were provided with the corresponding OCI tunnel details — including the VPN headend IP addresses and the auto-generated shared secrets — to complete the configuration on their end. The tunnels go live once both sides are aligned.
What We Delivered
End-to-end encryption.
All traffic between the client’s server and each vendor is encrypted with IPSec using IKEv2 — the current industry standard for secure tunnel negotiation.
Built-in redundancy.
OCI provisions two tunnels per vendor connection automatically. If one tunnel fails, traffic fails over to the backup with no disruption to live operations.
Precise traffic routing.
Route rules ensure that outbound traffic to each vendor travels only through its designated tunnel. There is no cross-contamination between vendor connections.
Vendor-ready handoff.
All OCI-side configuration is complete, staged, and verified. The tunnels activate the moment each vendor applies matching credentials and traffic selectors on their end.
Conclusion
This engagement demonstrates how a secure, scalable, multi-vendor connectivity solution can be delivered on Oracle Cloud Infrastructure. By centralising all VPN traffic through a single Dynamic Routing Gateway, the client now has a clean and auditable network architecture that meets their compliance obligations and is straightforward to extend as their partner network grows.
The outcome on the OCI side is a fully staged, validated environment featuring three independent IPSec tunnels, each built with dual redundancy, precise routing rules, and matching peer configurations. To guarantee operational readiness, we worked closely with each vendor to successfully verify that all three connections were fully established, performing connectivity testing—including ICMP pings and telnet port checks—to ensure traffic flows correctly from end to end based on each vendor’s respective environment.
Beyond this specific deployment, the approach taken here—using a single VCN and a centralized DRG to securely connect a single server to multiple external vendors—is a highly reliable pattern. By leveraging per-vendor CPE objects, isolated route rules, and redundant tunnel pairs tied to a single gateway foundation, this architecture serves as a perfect blueprint for any organization that needs to grant multiple third parties secure, streamlined access to a centralized resource.
Need Something Similar?
If your platform handles sensitive data exchange with external networks — and your compliance requirements demand dedicated, encrypted connectivity — we can design and deploy the full solution on OCI.
Get in touch to discuss your infrastructure requirements.
Appendix:
What Is a Site-to-Site VPN?
A site-to-site VPN creates a permanent, encrypted tunnel between two separate networks. Think of it as a private highway between two locations, completely invisible to the public internet. Unlike a personal VPN where a single user connects to a server, a site-to-site VPN links entire networks together at the infrastructure level. Once configured, all traffic between the two sides flows automatically through the encrypted tunnel — no user action required.
This is the standard approach when organisations need to exchange sensitive data with external partners securely. It eliminates exposure to the public internet entirely, provides strong mutual authentication between both sides, and meets the encryption requirements demanded by most industry regulations and compliance frameworks.
Industry Context
This type of deployment is especially relevant in regulated industries where network-to-network data exchange must meet strict security and compliance standards.
