Cloud · On-prem → Azure / AWS · Lesson 4 of 8

Path first: VPN now, ExpressRoute when the volume is real

You do not wait eight weeks for ExpressRoute to move one VM. This lab starts IPsec from fgt-hq 203.0.113.10 to Azure VPN GW 203.0.113.50 and/or AWS VGW 203.0.113.60. ExpressRoute / Direct Connect come later for stable high volume. DNS — conditional forwarder, Private DNS, Route 53 — is the silent breaker.

Updated 2026-08-18·20 min read·L2 primary·Quiz at end

After this page you can

Bring up FortiGate route-based IPsec to the Azure and/or AWS dummy peers.
Know when ER/DX is justified vs when VPN is enough for wave-1.
Design hybrid DNS before the first replica (the usual outage).
Prove Phase-1, Phase-2, route, and a sourced ping — not a green icon.

The ticket

Circuit order for ExpressRoute is in procurement. Meanwhile pay-api cannot be tested because there is no path. FortiGate already has a WAN. Azure already has VPN GW 203.0.113.50. Nobody built the tunnel. Separately: when they finally VPN, pings work and the app still dies — pay-api.techclick-lab.in still answers 10.20.30.40 from every resolver.

Quick interview answer

Wave-1 path is route-based IPsec: fgt-hq to Azure VPN Gateway and/or AWS Site-to-Site (VGW or TGW attachment). ExpressRoute and Direct Connect are for committed bandwidth, private peering, and a stability SLA — not for the first replica. After the SA is up you still need routes (hub UDR / TGW) and DNS: on-prem conditional forwarder on dc01, Azure Private DNS, Route 53 private hosted zone + Resolver. Green IKE with the wrong A record is a failed migration.

FortiGate IPsec to Azure VPN Gateway and AWS VGW — IKE up is not the app. DNS is usually the app.

Lab data · dummy only

On-prem DC dc01 10.20.30.10 · FortiGate fgt-hq 203.0.113.10 · same Azure landing as the Azure series and same AWS landing as the AWS series. Wave-1 app pay-api today on VM 10.20.30.40.

Mental model

Path	This lab	When
IPsec S2S	203.0.113.10 ↔ 203.0.113.50 (Azure) and/or ↔ 203.0.113.60 (AWS)	Start here
Azure hub	10.40.0.0/16 · Firewall 10.40.0.4 · spoke 10.41.0.0/16	Already in Azure series
AWS hub	10.50.0.0/16 · TGW tgw-lab · app 10.51.0.0/16	Already in AWS series
ExpressRoute / DX	Not in wave-1	Stable high volume, private peering, compliance
DNS	dc01 forwarder + Private DNS / Route 53	Before cutover, or the flip is theatre

Wave-1 paths

CIDRs do not overlap on-prem 10.20.30.0/24. Do not invent 10.20.30.0/24 in the cloud.

https://fgt-hq.techclick-lab.in

Training mock · not live

FortiGate

DashboardNetworkPolicy & ObjectsVPNLog & Report

VPN → IPsec Tunnels

vpn-azure + vpn-aws

Peer Azure

203.0.113.50 · IKEv2 · route-based

Peer AWS

203.0.113.60 · IKEv2 · route-based

Selectors / TS

10.20.30.0/24 ↔ 10.40.0.0/16 and 10.41.0.0/16

Also

10.20.30.0/24 ↔ 10.50.0.0/16 and 10.51.0.0/16

DNS

dc01 conditional forwarder for azure / amazonaws private names

FortiOS 7.4 IPsec to Azure VPN GW / AWS S2S. Training mock.

How to choose

VPN for wave-1. Add ER/DX when you have months of stable traffic, a bandwidth number, and a circuit owner — not because a slide said “private connectivity.” If you need both clouds, two tunnels from fgt-hq (or TGW + Azure hub each with their own). Do not hairpin production payments across a laptop VPN.

Runbook

Side A — IKE + IPsec
IKEv2, matching proposals, route-based. Azure: gateway subnet + connection. AWS: VGW or TGW VPN attachment. Phase-2 must cover LAN ↔ hub+spoke / hub+app — 0.0.0.0/0 vs a subnet is the FortiGate-to-cloud classic.
Side B — route + firewall
On-prem: 10.40.0.0/16 and 10.51.0.0/16 via the right tunnel. Azure UDR to Firewall 10.40.0.4 if that is the design. AWS TGW associations. Policies both ways on fgt-hq.
Side C — DNS before the flip
Lower TTL on pay-api.techclick-lab.in. Decide who will answer after cutover (dc01 A record vs Private DNS vs Route 53). Conditional forwarder on dc01 for privatelink.azure.com / Route 53 Resolver inbound. Prove with nslookup from a LAN client and from a spoke test NIC.

path proof · dummy

diagnose vpn ike gateway list
# vpn-azure  IKE SA established  peer 203.0.113.50
# vpn-aws    IKE SA established  peer 203.0.113.60

diagnose vpn tunnel list name vpn-azure
# selectors: 10.20.30.0/24-10.40.0.0/16  10.20.30.0/24-10.41.0.0/16

execute ping-options source 10.20.30.1
execute ping 10.40.0.4
# Azure Firewall answers ICMP only if you allowed it — TCP 443 to a test NIC is better

nslookup pay-api.techclick-lab.in 10.20.30.10
# today: 10.20.30.40   after flip: 10.41.1.40 or 10.51.1.40

Four failures

1 · ER/DX first

Wave-1 waits on a circuit. VPN would have been up this afternoon.

2 · Overlapping CIDR

If someone numbered the spoke 10.20.30.0/24, IPsec cannot route it. This lab does not overlap — do not create the overlap.

3 · SAs up, DNS lies

Clients still hit on-prem 10.20.30.40. The silent breaker. Fix the name, not the PSK.

4 · One-way selectors

Azure connection 0.0.0.0/0 vs FortiGate LAN-only. Phase-2 never quite matches. Align traffic selectors / use route-based both sides.

How to prove it

Close only when

1) IKE + IPsec up to the peer you will actually use. 2) Sourced ping or TCP from LAN CIDR to hub/spoke test IP. 3) nslookup story is written for before and after. 4) ER/DX is a later CR, not a gate.

Traps

Green	Still check
VPN connection Succeeded	Which SA, which prefixes, which UDR
ExpressRoute provisioned	Peering + route advertisement — not the same as “on”
Ping 10.41.1.40 works	What name did the app call?

On-prem to cloud migration class series: 6 Rs · Landing zone first · Identity first · VPN / ER / DX · Lift vs rebuild · Map controls · Cutover + rollback · Hybrid interview

Sources

Related: Azure landing zone · AWS Org / OU.