PROJECT 001
> cat hybrid-cloud-transit-vpc.md

HYBRID CLOUD
Transit VPC
& FortiGate NVA

An enterprise-style hybrid cloud build connecting an on-prem home lab to AWS through a dedicated Transit VPC, a FortiGate Network Virtual Appliance, AWS Transit Gateway, and dynamic routing over IPsec — designed as a reusable network hub, not a one-off VPN tunnel.

architecture live eBGP over IPsec VTI ASN 65001 ↔ 65002 Transit Gateway hub-and-spoke

Enterprise-inspired hybrid networking architecture using AWS Transit Gateway, FortiGate NVA, IPsec VTI and eBGP.

View Repository Back to Portfolio
cat overview.md

Why this exists

Project Summary

This project demonstrates an enterprise-inspired hybrid cloud architecture that securely connects an on-premises environment to AWS using a dedicated Transit VPC, a FortiGate Network Virtual Appliance (NVA), AWS Transit Gateway, Route-Based IPsec VPN, and dynamic eBGP routing. Rather than building a simple point-to-point VPN, the design focuses on scalability, centralized security, and reusable network services commonly found in enterprise environments.

Most home-lab hybrid cloud setups terminate a VPN straight into an application VPC. It works, but it doesn't scale — every new workload means another tunnel, another route, another one-off decision.

This build separates network infrastructure from application infrastructure. A dedicated Transit VPC acts as the network services layer, with a FortiGate VM running inside it as the Network Virtual Appliance — handling routing and security centrally — while AWS Transit Gateway fans connectivity out to application VPCs as they're added.

The first workload riding on this hub is an AdGuard Home instance, providing secondary DNS resolution back to the home lab. The point isn't the DNS server — it's that the next VPC just attaches to the Transit Gateway, with no redesign required.

show topology

Architecture at a glance

Traffic leaves the home lab over a route-based IPsec tunnel, lands on the FortiGate NVA inside the Transit VPC, and is handed to Transit Gateway for distribution to every attached VPC.

path — home lab to workload
HOME LAB IPSEC VTI eBGP FORTIGATE NVA transit vpc AWS TGW MAIN VPC AdGuard DNS FUTURE VPCS attach & go
Enterprise hybrid cloud architecture diagram
fig. 1 — full architecture diagram, home lab to AWS
show inventory

Technologies Used

AWSFortiGate VMTransit Gateway IPsec (VTI)eBGPProxmox OPNsenseAdGuard HomeAmazon Linux 2023 VPC / SubnetsRoute TablesENIs
show ip route

Network Layout

home lab
10.72.15.0/24Servers & infrastructure
192.168.69.0/24Home client devices
aws transit vpc
10.123.0.0/16Network services
10.123.20.0/24Public subnet
10.123.10.0/24Private subnet
FortiGate NVA
main application vpc
172.31.0.0/16Workloads
Amazon Linux utility server
AdGuard secondary DNS
show bgp neighbors

Dynamic Routing over eBGP

Routes are exchanged dynamically instead of statically — when an advertised prefix changes on either side, both ends learn it automatically.

FortiGate NVA
ASN 65001
OPNsense
ASN 65002

AWS learns

  • 10.72.15.0/24
  • 192.168.69.0/24

On-premises learns

  • 172.31.0.0/16
  • 10.123.0.0/16
no manual route updates required when advertised prefixes change
show design-rationale

Why a Transit VPC

A VPN dropped straight into an application VPC is a common lab pattern — it just doesn't hold up once more than one workload needs access.

Separation of Duties

The Transit VPC is a dedicated network services layer. Application workloads stay isolated from VPN termination and routing infrastructure.

Centralized Security

All hybrid traffic traverses the FortiGate firewall — one place for policy enforcement, logging, inspection, and future IPS/IDS.

Scalability

Future VPCs simply attach to the Transit Gateway. No additional VPN tunnels, no re-architecture — the same tunnel securely serves every attached VPC.

Enterprise Pattern

Mirrors how larger orgs actually do this — dedicated network hubs rather than VPNs terminated straight into workload VPCs, as seen in MSPs, financial institutions, and multi-account AWS Organizations.

Native AWS Site-to-Site VPN is solid, but it gives limited control over inspection and advanced routing. A FortiGate NVA trades a bit of simplicity for:

Stateful firewall policies Future IPS capability Full routing control Traffic visibility Vendor-neutral firewall
ls -la screenshots/

From the Lab

Live configuration and status output pulled directly from the on-prem and AWS sides of the tunnel.

OPNsense IPsec tunnel status
OPNsense — IPsec tunnel status
OPNsense BGP routing table
OPNsense — BGP routing table
AWS FortiGate NVA console
AWS — FortiGate NVA
FortiGate IPsec phase status
FortiGate — IPsec phase status
FortiGate interfaces
FortiGate — interfaces
AWS Transit Gateway route table
AWS — Transit Gateway route table
whoami

My Responsibilities

Architecture & Design

Designed the Transit VPC, AWS Transit Gateway topology, IP addressing, and hybrid connectivity strategy.

Implementation

Configured FortiGate NVA, Route-Based IPsec VPN, eBGP peering, VPC route tables, and deployed the Amazon Linux AdGuard workload.

Validation

Verified dynamic route exchange, end-to-end connectivity, hybrid DNS resolution, and documented the complete architecture.

git diff --stat

Current State & What's Next

committed — current features
+Dedicated Transit VPC
+AWS Transit Gateway
+FortiGate VM (NVA)
+Route-based IPsec VPN (VTI)
+eBGP dynamic routing
+Amazon Linux utility server
+AdGuard Home, hybrid DNS
+Separate transit & application VPCs
candidate-config — future enhancements
~Multi-AZ FortiGate HA
~Additional application VPCs
~AWS Inspection VPC
~AWS Network Firewall comparison
~Wazuh SIEM integration
~Route53 Resolver Endpoints
~Terraform deployment
~CI/CD with GitHub Actions
show notes

Lessons Learned

#AWS Transit Gateway architecture
#Network Virtual Appliance design
#Transit VPC patterns
#Route-based VPNs
#eBGP route advertisement
#AWS route table design
#Hybrid DNS architecture
#Cloud network segmentation
#Hub-and-spoke networking
#Designing for scale, not just today