|
Details about RPF can be found here:
https://community.fortinet.com/t5/FortiGate/Technical-Note-Details-about-FortiOS-RPF-Reverse-Path-Fo...
For packets in the original direction, RPF check takes place.
However, if the packet is received in the reply direction, FortiGate does not perform any RPF check.
Consider the following TCP traffic as an example:
1) The first packet (SYN) is received on port1 and then forwarded via port2.
2022-11-10 12:08:17.560388 port1 in 10.10.10.1.34284 -> 10.20.20.1.443: syn 1478946886
2022-11-10 12:08:17.560556 port2 out 10.10.10.1.34284 -> 10.20.20.1.443: syn 1478946886
2) The reply packet (SYN-ACK) is being received on port3 and it still gets forwarded to port1 without any RPF check being done.
2022-11-10 12:08:17.561235 port3 in 10.20.20.1.443 -> 10.10.10.1.34284: syn 3412372497 ack 1478946887
2022-11-10 12:08:17.561316 port1 out 10.20.20.1.443 -> 10.10.10.1.34284: syn 3412372497 ack 1478946887
3) The 3rd packet (ACK) is being received on port1 again and gets forwarded to port2.
2022-11-10 12:08:17.610491 port1 in 10.10.10.1.34284 -> 10.20.20.1.443: ack 3412372498
2022-11-10 12:08:17.610593 port2 out 10.10.10.1.34284 -> 10.20.20.1.443: ack 3412372498
Routing table looks as follows:
FGT-B # get router info routing-table details 10.10.10.1
Routing table for VRF=0
Routing entry for 10.10.10.0/24
Known via "static", distance 10, metric 0, best
* directly connected, port1 distance 0
FGT-B # get router info routing-table details 10.20.20.1
Routing table for VRF=0
Routing entry for 10.20.20.0/24
Known via "connected", distance 0, metric 0, best
* is directly connected, port2 distance 0
Despite traffic being received on port3 that has no route, FortiGate accepts the traffic. This is the expected behavior.
|
