FortiGate lab 9 of 25

Policy routes and reverse-path checks

Find out with debug flow why a monitoring service can't reach the firewall through the backup ISP, fix it the right way with route priority, then steer one workstation and all HTTPS traffic through ISP-B with policy routes.

Run this lab

It needs Lite: its 4 nodes are set to 4 vCPU and 5,632 MB in total. That fits the free demo too.

In your workspace: Shared, then FortiGate NSE 4 guided labs, then 09 - Policy routes and reverse-path checks

Try it free for 30 minutesRun it on Lite from £3 a day

The free demo needs no card and no email. Every lab plan includes every guided lab.

Level
Intermediate
Time
About 55 minutes
Nodes need
4 vCPU, 5,632 MB
Smallest plan
Lite

The scenario

Harbourside's monitoring provider pings both of the firewall's public addresses from 198.51.100.53. The ISP-A address answers, but 192.0.2.1 on ISP-B never does, even though ping is allowed on port3. Separately, the managed-service provider only trusts Harbourside's ISP-B address, so the admin workstation PC1 must always leave through ISP-B, and the backup software's HTTPS uploads should use ISP-B's cheaper bandwidth. Everything else stays on ISP-A.

DeviceInterfaceAddressConnects to
FGT1port1 (ISP-A)203.0.113.1/24ISP-A router 203.0.113.254 (INET eth0)
FGT1port3 (ISP-B)192.0.2.1/24ISP-B router 192.0.2.254 (INET eth1)
FGT1port2 (LAN)10.1.10.1/24PC1 10.1.10.10, H1 by DHCP

Routes at the start: default via ISP-A (distance 10) and a floating default via ISP-B (distance 20). Policies 1 and 2 allow the LAN out through either ISP with NAT.

What you’ll practise

  • Explain the reverse-path (anti-spoofing) check and its loose and strict modes
  • Use debug flow to spot a reverse-path drop
  • Keep a backup route in the routing table with priority instead of distance
  • Write source-based and port-based policy routes and check the route lookup order

The tasks

  1. Start the lab
  2. Reproduce the problem and trace it with debug flow
  3. Fix it with priority, not distance
  4. A source-based policy route for PC1
  5. A port-based policy route for HTTPS
  6. Strict RPF (optional experiment)

The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.

Topology and devices

The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.

Topology of Policy routes and reverse-path checks4 nodes and 1 network, 5 links. Every link is listed as text below the diagram.FGT1INETPC1H1LANport2eth0eth0port1eth0port3eth1
4 nodes and 1 network, with the interface names each link uses.
Nodes in Policy routes and reverse-path checks, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
FGT1Fortinet FortiGatefortinet-FGT-v7.0.17.M-build06821 vCPU, 2,048 MB
INETEVE-NG GUI server (Docker)eve-gui-server:latest1 vCPU, 1,024 MB
PC1EVE-NG GUI server (Docker)eve-gui-server:latest1 vCPU, 2,048 MB
H1Alpine Linuxclbalpinebase-alpine-base-3-20-31 vCPU, 512 MB

How to open this lab

  1. Sign in to your workspace at lab.cloudlabbox.com.

  2. In File Manager, open Shared, then the folder FortiGate NSE 4 guided labs.

  3. Open 09 - Policy routes and reverse-path checks and start its nodes, then open Lab Tasks for the scenario and the steps.

The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.

More FortiGate labs

All FortiGate labs

Related labs in other courses

CloudLabBox is independent of Fortinet. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.