Description
This article describes the behavior of asymmetric routing concerning reply direction traffic.
Scope
FortiGate.
Solution
Refer above network diagram :
In this example, asymmetric routing has been disabled on FortiGate-B and enabled on FortiGate-A
FortiGate-B # show full system settings | grep asym
set asymroute disable
set asymroute-icmp disable
set asymroute6 disable
set asymroute6-icmp disable
Auxilliary session is also disabled on FortiGate-B
FortiGate-B # config system settings
FortiGate-B # show full system settings | grep aux
set auxiliary-session disable
An ICMP echo request (ping) originates from a source system connected to FortiGate-B port3 (192.168.2.2) destined for 192.168.1.1
The request is received on port3 and sent out via port2 (underlay interface as per the routing table).
FortiGate-B # get router info routing-table details 192.168.1.1
Routing table for VRF=0
Routing entry for 192.168.1.1/32
Known via "static", distance 10, metric 0, best
* vrf 0 20.20.20.1, via port2
FortiGate-B # get router info routing-table details 192.168.2.2
Routing table for VRF=0
Routing entry for 192.168.2.0/24
Known via "connected", distance 0, metric 0, best
* is directly connected, port3
Packet Capture Taken On FortiGate-B :
2025-06-24 03:56:54.745453 port3 in 192.168.2.2 -> 192.168.1.1: icmp: echo request
2025-06-24 03:56:54.745509 port2 out 192.168.2.2 -> 192.168.1.1: icmp: echo request
So the direction of traffic in FortiGate-B, (ICMP echo request) packet coming in port3 to sending out via port2 is considered as the Original Direction of the Packet.
2025-06-24 03:56:54.765969 vpn1 in 192.168.1.1 -> 192.168.2.2: icmp: echo reply
2025-06-24 03:56:54.765994 port3 out 192.168.1.1 -> 192.168.2.2: icmp: echo reply
In the above capture, return traffic (ICMP echo reply) appears to be coming back to FortiGate-B via a different interface (vpn1), and it is sent back through the same ingress interface (port3).
So the direction of traffic in FortiGate-B, (ICMP echo reply) packet coming in vpn1 to sending out via port3 is considered as the Reply Direction of the Packet.
This packet is being accepted by the firewall without enabling asymmetric routing on FortiGate-B. The return traffic is accepted due to an existing session present in the firewall, and this packet is marked as dirty and updates the interface information.
FortiGate-B # diagnose system session list
session info: proto=1 proto_state=00 duration=2 expire=59 timeout=0 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ tun_id=20.20.20.1/0.0.0.0 vlan_cos=0/255
state=dirty may_dirty
statistic(bytes/packets/allow_err): org=120/2/1 reply=120/2/1 tuples=2
tx speed(Bps/kbps): 59/0 rx speed(Bps/kbps): 59/0
orgin->sink: org pre->post, reply pre->post dev=5->4/16->5 gwy=20.20.20.1/0.0.0.0
hook=pre dir=org act=noop 192.168.2.2:1->192.168.1.1:8(0.0.0.0:0)
hook=post dir=reply act=noop 192.168.1.1:1->192.168.2.2:0(0.0.0.0:0)
misc=0 policy_id=1 pol_uuid_idx=15853 auth_info=0 chk_client_info=0 vd=0
serial=00002f14 tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=0x000100
no_ofld_reason: npu-flag-off
total session: 1
FortiGate-B # diagnose ip address list
IP=10.254.1.5->10.254.1.5/255.255.255.0 index=3 devname=port1
IP=20.20.20.2->20.20.20.2/255.255.255.252 index=4 devname=port2
IP=192.168.2.254->192.168.2.254/255.255.255.0 index=5 devname=port3
FortiGate-B # diagnose netlink interface list | grep -f -A2 vpn1
if=vpn1 family=00 type=768 index=16 mtu=1420 link=0 master=0
ref=14 state=start present fw_flags=0 flags=up p2p run noarp multicast
This indicates that the firewall performs RPF (reverse routing lookup) check only for the Original Direction of the Source IP address, not for the Reply Direction traffic. It is expected behavior in FortiGate.
