Description
This article describes that reply TCP traffic for inbound local session uses a different egress interface with the same route than originate traffic even if Asymmetric routing and auxiliary session are disabled.
Scope
FortiGate v7.4.1. Expected to be fixed in v7.4.2.
Solution
The issue is caused by a bug/regression introduced in v7.4.1. If a route has the same distance and metric/cost with multiple interfaces associated, it starts performing ECMP for reply local TCP traffic.
get router info routing-table details 10.3.70.40
Routing table for VRF=0
Routing entry for 10.3.0.0/16
Known via "static", distance 1, metric 0, best
* via LasVegas_Pri tunnel 208.65.159.67 vrf 0
* via LasVegas_Sec tunnel 10.0.0.1 vrf 0
* via Irvine_Pri tunnel 10.0.0.2 vrf 0
* via Irvine_Sec tunnel 216.23.181.100 vrf 0
The client can be reached over 4 ECMP routes. As visible below, ICMP traffic is replied to using the correct interface, But the TCP reply traffic gets ECMP and chooses a different interface.
diagnose sniffer packet any "host 10.18.3.150" 4 0 l
interfaces=[any]
filters=[host 10.18.3.150]
2023-09-13 16:11:06.089235 Irvine_Pri in 10.3.70.40 -> 10.18.3.150: icmp: echo request
2023-09-13 16:11:06.089300 Irvine_Pri out 10.18.3.150 -> 10.3.70.40: icmp: echo reply <----- ICMP reply with correct interface.
2023-09-13 16:11:08.948826 Irvine_Pri in 10.3.70.40.2849 -> 10.18.3.150.443: syn 401881457
2023-09-13 16:11:08.948919 LasVegas_Pri out 10.18.3.150.443 -> 10.3.70.40.2849: syn 2410236231 ack 401881458 <----- TCP reply out via wrong interface.
2023-09-13 16:11:08.949142 Irvine_Pri in 10.3.70.40.2849 -> 10.18.3.150.443: ack 2410236232
The following are some final points regarding this bug:
- This issue only affects TCP traffic local to the FortiGate.
- The bug will not affect a setup in which there is only one route for local TCP traffic or there are multiple with different DISTANCE or metric/cost
