Sev1: OCI Site-to-Site VPN tunnels down — IPSec status, IKE settings, shared secret and DRG routing

#Symptoms

• On-premises users can't reach OCI apps, or OCI workloads can't reach on-premises databases and AD.
• Tunnels show DOWN in the console, or UP with no traffic.
• Often after an on-premises firewall upgrade, ISP change or Phase 1/2 setting change.

#1. Check tunnel status

IPSC=$(oci network ip-sec-connection list --compartment-id $COMP \
  --query "data[?\"display-name\"=='vpn-dc1'].id | [0]" --raw-output)
oci network ip-sec-tunnel list --ipsc-id $IPSC \
  --query 'data[].{id:id, status:status, ike:"ike-version", routing:routing, vpnIp:"vpn-ip", cpeIp:"cpe-ip", changed:"time-status-updated"}' \
  --output table

time-status-updated tells you exactly when it went down; match it to the change log on the on-premises side.

#2. Confirm the basics on the CPE side

• The CPE (customer-premises equipment) object's IP in OCI must match the on-premises public IP:

oci network cpe list --compartment-id $COMP --query 'data[].{name:"display-name", ip:"ip-address"}' --output table

• UDP 500 and 4500 and ESP must be allowed between the CPE and the two Oracle VPN headend IPs (vpn-ip above).
• If the on-premises device is behind NAT, the CPE IKE identifier must match what the device sends.

#3. IKE and IPSec settings

Read the tunnel's phase 1 and phase 2 details:

oci network ip-sec-tunnel get --ipsc-id $IPSC --tunnel-id <tunnel-ocid> \
  --query 'data.{ike:"ike-version", p1:"phase-one-details", p2:"phase-two-details", dpd:"dpd-mode"}'

Compare with the on-premises device: IKE version, encryption, integrity, DH group, lifetimes and PFS. A firmware upgrade that changed defaults is a classic cause. If you can't change the device quickly, align the OCI side by editing the tunnel's advanced settings in the console.

Shared secret: if either side changed it, IKE authentication fails. Reset it on both sides to the same value (console: Site-to-Site VPN > tunnel > Edit, or the oci network ip-sec-psk / tunnel shared secret commands in your CLI version; check oci network --help).

Warning

Changing tunnel settings on the OCI side renegotiates that tunnel. Change one tunnel at a time so the other keeps carrying traffic.

#4. Tunnel up, no traffic

BGP routing:

oci network ip-sec-tunnel get --ipsc-id $IPSC --tunnel-id <tunnel-ocid> --query 'data."bgp-session-info"'

Check bgp-state is UP and that on-premises advertises the expected prefixes.

Static routing: the static routes on the IPSec connection must cover the on-premises CIDRs.

DRG route tables and VCN attachments:

oci network drg-route-table list --drg-id $DRG --output table
oci network drg-route-rule list --drg-route-table-id <rt-ocid> --output table

VCN route table: the workload subnet needs a rule sending on-premises CIDRs to the DRG. Security lists/NSGs must allow the on-premises CIDR.

#5. Verify

# from an OCI instance
ping -c 3 10.50.1.10
nc -zvw3 10.50.1.10 1433

Watch the tunnel metrics (PacketsReceived, BytesSent) in the oci_vpn namespace climb again.

#Prevent it next time

• Use both tunnels with BGP so one tunnel's failure is invisible to users.
• Keep the agreed phase 1/phase 2 parameters in the runbook and in on-premises change templates.
• Alarm on tunnel state (TunnelState metric) for each tunnel.
• Consider FastConnect with VPN as backup for production hybrid traffic.