Connecting Microsoft Azure and Oracle Cloud Infrastructure (OCI) with an IPSec VPN provides encrypted private connectivity between workloads running in both clouds. This practical guide covers the architecture, gateway configuration, routing, security controls, validation, and common troubleshooting areas.

1. Reference architecture

The design connects an Azure Virtual Network (VNet) to an OCI Virtual Cloud Network (VCN). On Azure, the VPN Gateway provides the Azure-side IPsec connectivity. On OCI, a Dynamic Routing Gateway (DRG) and Site-to-Site VPN provide the OCI-side connectivity.

2. Plan the network CIDRs

Use non-overlapping address ranges before creating the VPN. For example:

• Azure VNet — 10.40.0.0/16
• Azure workload subnet — 10.40.10.0/24
• OCI VCN — 10.50.0.0/16
• OCI workload subnet — 10.50.10.0/24

Document which application subnets need connectivity and which protocols and ports are required.

3. OCI configuration

Create or identify the OCI VCN and attach a Dynamic Routing Gateway. Create an IPSec connection toward Azure and configure the required customer-premises-equipment definition and tunnel parameters. Record the OCI tunnel endpoint information and authentication details for the Azure configuration.

4. Azure configuration

Create an Azure VPN Gateway for the VNet and configure the gateway subnet according to Azure requirements. Create a Local Network Gateway representing the OCI network and its VPN endpoint. Create the VPN connection between the Azure VPN Gateway and the Local Network Gateway using compatible IPSec/IKE parameters.

5. IPSec and IKE parameters

Both cloud environments must use compatible tunnel settings. Define the IKE version, encryption, integrity, Diffie-Hellman group, lifetime values, and authentication method. When using a pre-shared key, the same key must be configured at both ends.

6. Routing

VPN establishment alone does not guarantee application connectivity. On OCI, route Azure VNet prefixes through the DRG. On Azure, ensure routes for the OCI VCN are directed through the VPN Gateway. If dynamic routing is used, verify that the expected prefixes are advertised and learned.

7. Security controls

Review OCI Security Lists or Network Security Groups and Azure Network Security Groups. Permit only the required source CIDRs, destination CIDRs, protocols, and ports. Check return traffic as well as the forward direction.

8. Validate the VPN

1. Confirm the VPN tunnels are established.
2. Verify OCI route tables contain the Azure prefixes.
3. Verify Azure routing contains the OCI prefixes.
4. Check OCI NSGs/security lists and Azure NSGs.
5. Test connectivity between selected workloads.
6. Validate application ports rather than relying only on ICMP.
7. Review gateway and VPN diagnostics if traffic fails.

9. Common troubleshooting areas

• Overlapping Azure and OCI CIDRs.
• Incorrect or incompatible IKE/IPSec parameters.
• Incorrect pre-shared key.
• Missing gateway attachment or incorrect gateway configuration.
• Missing route-table entries.
• NSG, security-list, or host firewall restrictions.
• Return-path or asymmetric-routing problems.

10. Production considerations

Use redundant VPN tunnels and design routing for failure scenarios. Keep the address plan documented, restrict security rules, monitor tunnel state, and test failover before relying on the connection for production workloads.

Conclusion

An Azure-to-OCI IPSec VPN depends on correct alignment between the Azure VPN Gateway, OCI DRG and Site-to-Site VPN, routing, and workload security controls. A structured validation process makes it easier to distinguish tunnel-negotiation problems from routing or application-security problems.

Note: Cloud provider consoles and supported VPN options can change. Validate the exact Azure and OCI service configuration against the current provider documentation before implementing the design in production.