Multi-vendor · IPsec / SSL-VPN · Lesson 4 of 8

New design: route-based tunnel interface, then a route

Route-based IPsec is a tunnel interface plus a route (and ordinary policies). Policy-based stuffs interesting traffic into the policy; the proxy IDs come from that pair. Cloud peers (Azure route-based VNet GW, AWS S2S) are route-based. Build policy-based only when the far end is documented as policy-based.

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

After this page you can

Draw VTI + route + two policies for this lab.
Say when policy-based is forced on you.
Prove the route lookup hits the tunnel interface.
Not SNAT into the tunnel unless that is the design.

The ticket

Both SAs are up. Priya still cannot reach 10.30.0.10. get router info routing-table details 10.30.0.0 points at WAN, not vpn-branch. You negotiated IPsec and then routed around it. Policy-based would have hidden the same miss inside “interesting traffic.”

Quick interview answer

Route-based (FortiOS IPsec tunnel interface / VTI): Phase-1/2 create vpn-branch, you add a route to 10.30.0.0/24 via that interface, then firewall policies LAN → vpn-branch and reverse. Policy-based: the policy’s src/dst become the selectors; there is no useful tunnel if for routing. FortiOS 7.4 wizard defaults to route-based. Azure VPN Gateway and AWS Site-to-Site are route-based for new work. Policy-based Azure is Basic + IKEv1 and is not a portal default.

Route-based VTI versus policy-based interesting traffic — Green SA plus a route to WAN is still a down LAN.

Lab data · dummy only

FortiGate fgt-hq mgmt 10.10.10.1 · WAN 203.0.113.10 · LAN 10.20.30.0/24 · FortiManager 10.10.10.5 · FortiAnalyzer 10.10.10.6 · Priya 10.20.30.80 · branch peer WAN 198.51.100.10 · Azure VPN GW public 203.0.113.50 · AWS VGW public 203.0.113.60. RFC 5737. Not a customer.

Mental model

	Route-based	Policy-based
What steers traffic	Route to tunnel if `vpn-branch`	Policy match = interesting traffic
Selectors	Often 0/0 or a few Phase-2s; routing decides	Tied to each policy pair
This lab	10.30.0.0/24 device vpn-branch	Only if the peer cannot do VTI
Cloud	Azure RouteBased, AWS S2S	Azure PolicyBased / Basic, IKEv1
Proof	routing-table + tunnel list + policyid	Policy hit and child SA for that pair

Packet walk on a route-based tunnel

Skip the route and the packet never becomes ESP.

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

Training mock · not live

FortiOS

DashboardNetworkVPNPolicy

Network → Static Routes

10.30.0.0/24 via vpn-branch

Destination

10.30.0.0/24

Interface

vpn-branch (IPsec tunnel)

Gateway

None (point-to-point tunnel if)

Blackhole backup

Optional, so LAN does not leak to WAN if tunnel dies

Policies

LAN → vpn-branch and vpn-branch → LAN, NAT off

FortiOS 7.4 route-based IPsec: tunnel interface + route + policies. Training mock.

How to choose

New design: route-based + IKEv2. Policy-based only when the peer’s vendor doc says policy-based (legacy firewall, Azure PolicyBased/Basic). Mixing a route-based FortiGate with a policy-based peer is how you inherit the 0/0 vs /24 ticket from lesson 3.

Runbook

Side A - tunnel if
VPN → IPsec Tunnels created vpn-branch. get sys interface shows it. IP on the tunnel if is optional for static routing.
Side B - route + policy
Static (or BGP) 10.30.0.0/24 via vpn-branch. Policies both ways. NAT disabled unless you designed SNAT.
Side C - prove
Route lookup, tunnel list, sourced ping, and the reverse from the branch. debug flow dest-intf must be vpn-branch, not port1.

fgt-hq · route-based proof

get router info routing-table details 10.30.0.0
# Routing table for VRF=0
# Routing entry for 10.30.0.0/24
#   * directly connected, vpn-branch

get firewall policy
# srcintf: LAN  dstintf: vpn-branch  nat: disable
# srcintf: vpn-branch  dstintf: LAN  nat: disable

diagnose vpn tunnel list name vpn-branch
execute ping-options source 10.20.30.1
execute ping 10.30.0.10

Four failures

1 · SAs up, route via WAN

Default route wins. Add the more-specific 10.30.0.0/24 to vpn-branch.

2 · SNAT into the tunnel

Branch sees 203.0.113.10, not 10.20.30.80. Their encryption domain and return route are wrong. Turn NAT off on the VPN policies unless that is the design.

3 · One-way policy

HQ allows LAN → vpn-branch. Branch has no return policy. Asymmetric drop.

4 · Policy-based on a cloud route-based peer

Azure RouteBased and AWS S2S expect a VTI-style peer. Do not force policy-based “because we always did.”

How to prove it

Close only when

1) Route to the far LAN is the tunnel if. 2) Policies both ways, NAT as designed. 3) Bidirectional sourced ping. 4) debug flow dest-intf is the tunnel, not WAN.

Traps

Symptom	Look at	Wrong fix
SAs up, ping dead	Route + dest-intf + NAT	New PSK
Cloud peer “needs policy-based”	Their current VPN type, not folklore	Convert Azure to Basic/IKEv1
Return traffic missing	Far-end route and policy	Another Phase-2 for the same pair

VPN scenario class series: S2S vs RA vs ZTNA · Phase-1 down · Phase-2 / proxy ID · Route vs policy · SSL split tunnel · FGT → Azure · FGT → AWS · VPN interview

Sources

Related: FortiGate IPsec · Azure hub-spoke · AWS TGW.