Firewalls and VPNs lab 15 of 16
Asymmetric routing and stateful firewalls
A routing change sends replies back through a different firewall from the one the request used. Find the three places the traffic dies (an IOS strict uRPF check, the FortiGate session table and the ASA's TCP state check) with each vendor's own tools, then fix the routing rather than switching the safety checks off.
Run this lab
It needs Lite: its 6 nodes are set to 6 vCPU and 6,144 MB in total. That fits the free demo too.
In your workspace: Shared, then Firewalls and VPNs multi-vendor guided labs, then 15 - Asymmetric routing and stateful firewalls
- Level
- Intermediate
- Time
- About 75 minutes
- Nodes need
- 6 vCPU, 6,144 MB
- Smallest plan
- Lite
The scenario
Pennard Hosting's web server (SRV, 10.10.0.10) sits behind two firewalls. Customers reach it through the ASA; the FortiGate is only meant for the servers' own outbound updates. Last night someone pointed CORE's default route at the FortiGate "to spread the load". This morning customers can't reach the web server. Find out where the traffic dies, on each device, before you fix it.
| Device | Interface | Address | Notes |
|---|---|---|---|
| EDGE | Gi0/0 / Gi0/1 / Gi0/2 | 192.0.2.254 / 198.51.100.254 / 203.0.113.1 (/24) | Sends 10.10.0.0/24 to the ASA |
| CUST-FW (ASA) | inside / outside | 10.0.1.1/24 / 192.0.2.1/24 | ACL OUTSIDE-IN allows web and ping to SRV |
| FGT | port2 / port1 | 10.0.2.1/24 / 198.51.100.1/24 | Policy 1 lets the servers out (no NAT) |
| CORE | Gi0/0 / Gi0/1 / Gi0/2 | 10.10.0.1 / 10.0.1.2 / 10.0.2.2 (/24) | Strict uRPF on Gi0/1; default route to the FortiGate |
| SRV | Gi0/0 | 10.10.0.10/24 | Web server |
| REMOTE | Gi0/0 | 203.0.113.10/24 | A customer; also runs a web server |
What you’ll practise
- Explain why stateful firewalls and strict uRPF drop asymmetric traffic
- Read IOS uRPF counters and compare strict and loose mode
- Read the FortiGate packet flow with diagnose debug flow and recognise a missing session
- Read the ASA connection table and accelerated-security-path drop counters
- Restore symmetric routing and know the risky escape hatches (TCP state bypass, asymroute)
The tasks
- Reproduce the fault and draw both paths
- The first drop: strict uRPF on CORE
- The second drop: no session on the FortiGate
- The third drop: the ASA's TCP state check
- Fix the design, not the checks
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.
Every link, as text
- EDGE
Gi0/0to CUST-FWGi0/1 - EDGE
Gi0/1to FGTport1 - EDGE
Gi0/2to REMOTEGi0/0 - CUST-FW
Gi0/0to COREGi0/1 - FGT
port2to COREGi0/2 - CORE
Gi0/0to SRVGi0/0
| Node | Device | Image in Add Node | Set to |
|---|---|---|---|
| EDGE | Cisco IOSv | vios-adventerprisek9-m.spa.159-3.m9 | 1 vCPU, 512 MB |
| CUST-FW | Cisco ASAv | asav-9.22.1.1-PLR-Licensed | 1 vCPU, 2,048 MB |
| FGT | Fortinet FortiGate | fortinet-FGT-v7.0.17.M-build0682 | 1 vCPU, 2,048 MB |
| CORE | Cisco IOSv | vios-adventerprisek9-m.spa.159-3.m9 | 1 vCPU, 512 MB |
| SRV | Cisco IOSv | vios-adventerprisek9-m.spa.159-3.m9 | 1 vCPU, 512 MB |
| REMOTE | Cisco IOSv | vios-adventerprisek9-m.spa.159-3.m9 | 1 vCPU, 512 MB |
How to open this lab
Sign in to your workspace at
lab.cloudlabbox.com.In File Manager, open Shared, then the folder
Firewalls and VPNs multi-vendor guided labs.Open
15 - Asymmetric routing and stateful firewallsand 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 Firewalls and VPNs labs
Related labs in other courses
CloudLabBox is independent of Check Point, Cisco, CompTIA, Fortinet, Juniper Networks, MikroTik, Netgate and Palo Alto Networks. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.