Step 10 · Connectivity & network security · 10

STEP 10 — FastConnect, IPSec VPN & Network Security

Design, govern, build and validate resilient hybrid connectivity with controlled traffic inspection.

Connect the customer's on-premises and branch networks to OCI through an approved FastConnect and/or Site-to-Site VPN architecture. Define routing, encryption, segmentation and inspection before implementation. Validate business connectivity, failover, firewall enforcement and operational evidence before customer acceptance.

Scope and boundary:This chapter covers customer-managed OCI hybrid networking and security: upgraded DRG, FastConnect private virtual circuits, Site-to-Site VPN, OCI Network Firewall (NFW) or an approved third-party NGFW, NSGs, route tables, DNS, logging and operational handover. Oracle-managed Fusion infrastructure and service-managed networking remain outside customer VCN control. Record the supported access pattern for OIC, ATP, FDI/OAC and Object Storage separately.

Manual execution:Engineers perform every OCI change by hand under an approved change. The portal records design, ownership, tasks, evidence, exceptions and approvals only; it never executes OCI changes, requests cloud credentials or implies deployment. OCI Network Firewall (NFW) is not an OCI Network Security Group (NSG).

Where Step 10 fits in the six-stage model

Step 10 is a cross-cutting chapter, not a new stage. Its tasks are added to the existing six stages. Order FastConnect during discovery — never wait until after go-live.

Stage	Step 10 work
01 · Governance	Discovery questionnaire, ADRs for connectivity pattern, encryption and firewall product; start provider ordering and lead-time tracking.
02 · Day 0	Network, security and provider owners named; addressing plan and CIDR overlap check approved.
03 · Landing zone	Upgraded DRG, attachments, route tables/import distributions, security VCN, NFW or NGFW, NSGs and DNS built.
04 · Workloads	FastConnect virtual circuits and VPN tunnels activated; approved flow matrix enables workload onboarding.
05 · Validation	N10-T01–N10-T12 executed: routing, enforcement, failover, throughput and alarm tests.
06 · Documentation	As-built diagrams, route and flow inventories, runbooks, provider escalation and customer acceptance.
Step 7 · DR	Recovery-region connectivity and backup capacity link to the DR register.

10.1 Discovery, prerequisites and design decisions

Collect every item before design. Use “Not yet known” with an owner rather than leaving a field blank.

Group	Collect
Business needs	Customer/project, tenancy reference, region/realm, environments, compartments, data classification, business owner, critical applications, acceptable connectivity outage, maintenance windows.
Network inventory	On-premises sites and CIDRs, hub/spoke VCN and subnet CIDRs, overlapping ranges, current routers/firewalls, DNS zones and resolver endpoints.
Connectivity	Normal/peak bandwidth, latency/loss/jitter targets, carrier lead time, CPE vendor/model/software, public IP or NAT situation, customer ASN, BGP peering addresses, DR-region requirements.
Security	Approved application flows, inspection requirements, encryption scope, TLS decryption stance, egress policy.
Operations	OCI, network, security and provider owners; notification destinations; escalation contacts; secret-store owner.

Record each decision as an ADR with decision, alternatives, rationale, consequences, owner, reviewer, date and approved version:

FastConnect + VPN, redundant FastConnect + VPN, VPN-only or not applicable.

Private versus public peering — default to private connectivity for private workloads.

Provider, locations, physical-path and last-mile diversity.

Encryption scope: application TLS, IPSec over FastConnect, eligible MACsec or an approved combination.

Managed OCI Network Firewall versus third-party NGFW.

Central versus distributed inspection, and approved bypass exceptions.

Active/standby versus multipath routing, including session-symmetry implications.

Regional recovery connectivity and backup capacity.

Address overlap:Overlapping CIDRs never receive a green design status without a documented resolution or approved exception. Use the overlap checker on this page; it parses CIDRs numerically rather than comparing strings.

10.2 Connectivity option comparison

Pattern	Suitable use	Required design evidence
VPN-only	Initial deployment, small sites or approved lower-criticality workloads	Two configured tunnels, CPE/ISP risks, capacity and application tests
FastConnect + internet VPN backup	Predictable private primary path with independent backup transport	Provider path, both VPN tunnels, route preference, degraded-mode capacity
Two diverse FastConnect paths + VPN	Higher-criticality connectivity	Failure-domain diversity, per-path capacity, tested single and dual circuit failure
IPSec over FastConnect	Encrypted traffic carried over private transport	Separate transport and overlay routing, encryption enforcement and recovery design

Privacy is not encryption:FastConnect provides private dedicated connectivity; it is not proof of encryption. A VPN carried over the same FastConnect circuit is not an independent backup for that circuit — record a separate internet backup path when physical independence is required.

10.3 FastConnect engineering playbook

#	Owner	Action	Evidence
1	Customer sponsor + network owner	Approve bandwidth, region, connectivity model, provider quote, responsibilities and delivery lead time.	Signed quote, lead-time record, ADR
2	Network owner	Select Oracle partner, third-party provider or colocation model. Confirm supported speeds and locations from current Oracle documentation.	Provider confirmation
3	Network engineer	Record circuit/connection IDs, provider service keys where applicable, VLAN/peering parameters, customer ASN, Oracle ASN, BGP addresses and allowed prefixes for the chosen model.	Circuit record
4	OCI engineer	Create or confirm the upgraded DRG, attachments and narrowly scoped route import distributions.	DRG route inventory
5	OCI engineer + provider	Establish private virtual circuits; coordinate provider-side activation and CPE configuration.	Virtual circuit state
6	Network engineer	Restrict route advertisements and imports. Record on-premises and OCI preferences separately — MED alone is not a universal failover control.	Prefix lists, preference record
7	Network engineer	Validate circuit and BGP status, learned/advertised prefixes, application reachability, DNS, MTU and achievable throughput.	Test results N10-T02, T04, T10
8	Network + operations	Test each failure domain and restoration under an approved maintenance plan.	Test result N10-T08, change record

Production target: diverse routers, carrier paths, points of presence or locations where available and justified. Two logical virtual circuits on one physical path do not establish physical redundancy. List remaining common CPE, power, carrier, last-mile and site dependencies.

Encryption:MACsec depends on compatible equipment, eligible cross-connects and provider support; it protects a link segment and is not end-to-end encryption. Keep a transport-encryption assessment and Vault secret references — never raw keys.

IPSec over FastConnect: the private virtual circuit is the transport; a CPE object is created in the dedicated mode for this option; the IPSec overlay runs across it using Oracle-managed tunnel endpoints; the virtual-circuit attachment and the IPSec attachment each use their own DRG route table and import distribution; an encrypted-only option can prevent unencrypted traffic over the circuit. Follow the official FastConnect encryption guidance — the portal does not generate OCI commands.

10.4 Site-to-Site IPSec VPN engineering playbook

1. Verify CPE model, software and supported parameters against current Oracle and vendor guidance. “IPSec-capable” is not proof of interoperability.

2. Record CPE address, IKE identity, NAT requirements, DRG and the approved route-based (or exceptional policy-based) design.

3. Create the IPSec connection and configure both OCI-provided tunnels. Both tunnels share customer-side dependencies unless separate CPEs/ISPs are designed.

4. Prefer BGP where supported. Record per-tunnel inside addresses, ASN, allowed routes and failover behaviour; document static-routing exceptions.

5. Agree matching IKE (Phase 1) and IPSec (Phase 2) proposals, PFS, lifetimes, DPD, NAT-T and MTU/MSS separately. Prefer IKEv2 and a supported modern profile verified for the realm and device. GCM includes integrity — no separate Phase 2 hash is required.

6. Reference per-tunnel shared secrets through an approved secret store. The portal stores references and rotation metadata only.

7. Validate both tunnel states, BGP, learned routes, rekey stability, NAT behaviour, DNS and application sessions.

8. Test tunnel loss, CPE/ISP loss where independently redundant, FastConnect loss, recovery and degraded capacity.

Asymmetry:Multiple VPN paths can return traffic asymmetrically. Test actual routing through stateful firewalls; marking a tunnel standby does not guarantee symmetric forwarding. Do not hard-code DPD intervals, convergence time or throughput guarantees.

10.5 Network security and firewall selection

Option	Management model	Licensing	HA responsibility	Notes
OCI Network Firewall	Oracle-managed service; policy managed by customer	OCI consumption pricing — obtain current quote	Service-managed within its documented design	Recommended managed baseline when its capabilities meet approved requirements
Palo Alto VM-Series	Customer-managed appliances on OCI compute	BYOL or marketplace — quote required	Customer designs and tests HA	Source document's default; reference choice requiring an ADR
Fortinet FortiGate	Customer-managed appliances	BYOL or marketplace — quote required	Customer designs and tests HA	Validate supported OCI topology and skills
Check Point CloudGuard	Customer-managed appliances	BYOL or marketplace — quote required	Customer designs and tests HA	Validate supported OCI topology and skills
Cisco Secure Firewall	Customer-managed appliances	BYOL or marketplace — quote required	Customer designs and tests HA	Validate supported OCI topology and skills
Zscaler Internet Access	SaaS egress security	Subscription	Vendor-managed	Optional internet-egress service; not a replacement for hybrid or east–west inspection

Product selection requires an ADR covering inspection requirements, session handling, supported topology and operating skills. Do not claim universal active-active HA or deploy appliances automatically.

Default-deny policy with explicit approved flows and logged decisions where supported.

NSGs control workload access; NFW inspects only traffic routed through it. Security lists and NSGs do not create inspection paths.

WAF protects supported HTTP ingress; the NGFW addresses routed traffic. Neither replaces IAM or application authorization.

Define IDS/IPS mode, permitted applications/ports and domain/URL controls where supported.

TLS decryption needs a separate approved decision (privacy, certificates, exclusions, performance). Without it, do not claim full payload inspection.

Define egress permissions, DNS control, service endpoints, management access and production/non-production segmentation.

NAT translates addresses and does not enforce an FQDN allowlist. Service Gateway provides a private Oracle service path and does not guarantee inspection.

Cloud Guard complements posture monitoring; record verified detector coverage and IaC drift checks rather than assuming every network change is detected.

10.6 Routing and inspection design

The diagrams on this page show hybrid, east–west and egress inspection with forward and return paths. A drawn firewall is not proof of enforcement — routes and logs are.

Object	What it does
DRG route table	Destination → DRG attachment. Import distributions decide which routes are learned.
VCN ingress route table (on the VCN attachment)	Destination → supported intra-VCN target, including the firewall private IP where applicable.
Subnet route table	Workload return and egress path to the firewall or a supported gateway.
Firewall subnet route table	Onward routing to the destination or to the DRG/gateway.

Common mistake:Never put a firewall private IP in a DRG attachment route table as if it were an attachment target. For central hub/spoke inspection, DRG attachment routing must send selected flows to the security VCN, through the firewall, and on to the destination attachment. On-premises-to-spoke routes must not silently bypass inspection, and broad import distributions must not let spoke-to-spoke traffic bypass. Same-VCN subnet inspection needs explicit intra-VCN routing; cross-VCN inspection is a separate design.

Route inventory column	Flow matrix column
Environment, owner	Flow ID
Table type/name	Source / destination zones and CIDRs
Associated attachment, subnet or gateway	Protocol / port, application
Destination	Business purpose
Route source (static/import)	Inspection device / policy
Target type/reference	Encryption, DNS dependency
Inspection requirement	Owner, approval, expiry
Return-path reference	Positive / negative tests
Change record, verification evidence

10.7 Observability and operations

Record only metrics each service actually publishes: FastConnect virtual-circuit and BGP state, VPN tunnel state, VCN flow logs, firewall traffic/threat logs, OCI Audit, DNS troubleshooting and SIEM forwarding. For each alarm record the baseline, warning/critical threshold, evaluation window, notification destination reference, responder, escalation, retention and evidence. Thresholds are customer-approved configuration, not promises. Values not fed by a verified integration are shown as “Not connected — manually recorded”.

Runbooks: connectivity loss; BGP flap or route withdrawal; VPN rekey or tunnel failure; asymmetric traffic; firewall block; DNS failure; MTU blackhole; provider outage; certificate/secret rotation; regional recovery; rollback.

Cost worksheet (dated): region and currency, circuit bandwidth/port charges, provider and last-mile charges, firewall service or compute/licence/support, logging/SIEM storage, DR connectivity, quotation links and assumptions. No historical estimates are preloaded as current pricing.

10.8 Validation, approvals and handover

Test	Requirement
N10-T01	No unresolved CIDR overlap; approved addressing and DNS resolution.
N10-T02	Both intended FastConnect paths and BGP sessions established (FastConnect designs).
N10-T03	Both VPN tunnels configured and application-tested (VPN designs).
N10-T04	Expected route import/export; unexpected routes rejected.
N10-T05	Allowed application transactions succeed across each intended path.
N10-T06	Unauthorized ports, zones and destinations blocked with evidence.
N10-T07	Firewall traversal proven by policy/log evidence for forward and return paths; bypass tests fail.
N10-T08	Each FastConnect path failure and primary-to-backup transition (FastConnect designs).
N10-T09	Each VPN tunnel failure, recovery and rekey (VPN designs).
N10-T10	Throughput, latency/loss/jitter and MTU/MSS meet agreed normal and degraded thresholds.
N10-T11	Alarms reach the operational destination and logs arrive in the SIEM within the agreed delay.
N10-T12	Rollback, recovery connectivity and handover documentation verified.

Each test records applicability, prerequisite, procedure, expected result, actual result, measured value and unit, pass/fail/not-run, executor, reviewer, timestamp and evidence references. Ping alone does not prove application readiness; a diagram alone does not prove inspection. VPN-only designs mark N10-T02 and N10-T08 not applicable with an approved reason; FastConnect-only designs do the same for N10-T03 and N10-T09.

Status path: Draft → Design Review → Approved for Build → Build Recorded → Validation → Customer Accepted, with Blocked and Changes requested states — using the project's existing task, approval and sign-off workflow. Required approvals: architecture and encryption design; firewall rules/security review; production change window; validation and customer acceptance. Separate executor and reviewer; a changed approved configuration needs re-approval.

Completion:All applicable mandatory tests passed, evidence accepted, as-built diagrams and route/flow inventory updated, runbooks and provider escalation recorded, and customer sign-off. Not-applicable needs an approved reason; accepted risks need an owner, expiry and approval. Failed controls are never counted as passed.

Governance register NET-10-01 – NET-10-12

Control	Requirement
NET-10-01	Approved architecture and non-overlapping addresses
NET-10-02	Explicit private-connectivity and encryption decision
NET-10-03	Documented circuit and customer-side failure domains
NET-10-04	Both applicable VPN tunnels configured
NET-10-05	Controlled route import/export and preferences
NET-10-06	Approved firewall product, policy and inspection scope
NET-10-07	Verified inspection paths and return routing
NET-10-08	Approved least-privilege application flow matrix
NET-10-09	Protected secret references and rotation ownership
NET-10-10	Verified logs, alarms and escalation
NET-10-11	Tested failure/recovery and degraded capacity
NET-10-12	Approved as-built documentation and handover

Source and boundary:Firewall options and FastConnect/IPSec VPN patterns are drawn from chapters 24 and 25 of the supplied source; its Palo Alto VM-Series default is retained as an attributed reference choice. Its price estimates, throughput, vendor-compatibility and cipher examples are not published as current facts. Verify every configuration against the official Oracle references below (reviewed 6 October 2026); they guide human implementation and do not guarantee support in every region.

Illustrative design diagrams. CIDRs are placeholders — replace with customer-approved ranges. Diagrams do not reflect or change any live OCI configuration.

Diagram A — Hybrid connectivity with central inspection

On-premises edge connects over diverse FastConnect A and B and a separate internet VPN with two tunnels to an upgraded DRG. The DRG routes selected flows to the security VCN where OCI Network Firewall inspects them before they reach workload spokes. Return traffic from spokes is routed back through the firewall before the DRG.

Diagram B — East–west spoke-to-spoke inspection

Traffic from spoke A enters the DRG, where the spoke attachment route table sends it to the security VCN attachment. The VCN ingress route table targets the firewall private IP; after inspection the firewall subnet route table sends it back to the DRG, which forwards it to the spoke B attachment. The reverse path follows the same firewall. Route configuration, not the drawing, creates inspection.

Diagram C — Controlled egress

A private workload's subnet route table sends egress to the firewall. After inspection, internet-bound traffic leaves through the NAT Gateway and Oracle service traffic through the Service Gateway. Internet destinations and Oracle service destinations are kept separate. Return traffic must route back through the firewall.

CIDR overlap checker

Design aid only — one CIDR per line, optional label after a space. Nothing is saved or sent anywhere; record approved results in your project.

Overlap: 10.10.0.0/16 ↔ 10.10.4.0/24 — needs a resolution or approved exception

Official Oracle references

Reviewed 6 October 2026.