Description
This article describes what happens to TCP, UDP, and ICMP packets when they arrive as asymmetric flows on a FortiGate.
It may be seen that hosts on some networks cannot reach certain other networks. This can occur when request and response packets follow different paths and do not cross the same firewall. This behavior is known as asymmetric routing. If a FortiGate receives the response packets, but not the requests, by default it blocks the packets as invalid.
If for some specific reason, it is required that the FortiGate unit should permit asymmetric routing, it can be configured by using the following CLI commands per VDOM:
config vdom
edit <vdom_name>
config system settings
set asymroute enable
end
end
Scope
FortiGate.
Solution
When asymmetric routing is enabled, the firewall will behave as follows.
For TCP packets:
- If the packet is an SYN, the FortiGate creates the session, checks the firewall policies, and applies the configuration of the matching policy (UTM inspection, NAT, Traffic shaping, etc.). The subsequent packets of the session can be offloaded (exactly as when asymmetric routing is disabled).
- If the packet is not a SYN but the session already exists on the firewall, then the FortiGate lets the traffic pass through (exactly as it would do when asymmetric routing is disabled).
- If the packet is not an SYN and the session does not exist (asymmetric routing), then all packets are passed to the CPU, and the FortiGate does not look up for matching firewall policies. Since no policy is matched, the packet is simply forwarded based on the routing table and the Firewall acts as a router that only makes routing decisions. No security inspection will be performed:
53.147018 wan in 1.1.1.2.80 -> 10.255.130.210.18929: syn 2874238539 ack 2874127433
53.147237 dmz out 1.1.1.2.80 -> 10.255.130.210.18929: syn 2874238539 ack 2874127433
id=20085 trace_id=6 func=print_pkt_detail line=4471 msg="vd-root received a packet(proto=6, 1.1.1.2:80->10.255.130.210:18929) from wan. flag [S.], seq 2874238539, ack 2874127433, win 32768"
id=20085 trace_id=6 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.255.130.210 via dmz"
53.155221 wan in 1.1.1.2.80 -> 10.255.130.210.18929: psh 2874238540 ack 2874127673
53.155364 dmz out 1.1.1.2.80 -> 10.255.130.210.18929: psh 2874238540 ack 2874127673
For ICMP packets:
For ICMP packets the rule is the same as for TCP packets. When asymmetric routing is enabled, if the ICMP packet is not a request and the session does not exist on the FortiGate, the ICMP reply will be routed if a route exists on the routing table without security inspection.
For ICMP packets addressed to the FortiGate interfaces:
In FortiOS 7.2.5 and earlier: If the ICMP request originates from an asymmetric path, the FortiGate sends the reply through the same path.
In FortiOS 7.2.6 and later: If the ICMP request originates from an asymmetric path, the FortiGate does not send the reply through the same path, resulting in ping failure.
For UDP packets:
UDP packet is checked by the session table regardless of asymmetric routing. Asymmetric routing does not affect UDP packets. In order to allow UDP, a policy is needed to allow it.
id=20085 trace_id=12 func=print_pkt_detail line=4471 msg="vd-root received a packet(proto=17, 1.1.1.2:53->10.255.130.210:1024) from wan. "
id=20085 trace_id=12 func=init_ip_session_common line=4624 msg="allocate a new session-0003db5e"
id=20085 trace_id=12 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.255.130.210 via dmz"
id=20085 trace_id=12 func=fw_forward_handler line=561 msg="Denied by forward policy check (policy 0)"
68.235893 wan in 1.1.1.2.53 -> 10.255.130.210.1024: udp 52
71.228558 wan in 1.1.1.2.53 -> 10.255.130.210.1024: udp 52
74.228675 wan in 1.1.1.2.53 -> 10.255.130.210.1024: udp 52
The reason why asymmetric routing is not recommended is because of TCP Point 3 and ICMP.
However, the feature could be used in some cases where it is required. It is important to be aware of the constraints when the feature is enabled (no policy lookup and no UTM inspection).
Additionally, packets i.e. TCP or ICMP, can enter through any ports and still be matched to any policy ID, even if that policy is not intended for traffic, leading to the firewall traffic originating from a different interface, resulting in unexpected behavior in logs.
For Stream Control Transmission Protocol (SCTP) Traffic.
The SCTP traffic is part of the Transport Layer for the OSI Model as TCP and UDP.
The SCTP provides some features of both protocols.
- If the Asymroute is enabled, the FortiGate will forward the traffic to the route that has the Destination.
- If the Asymroute is disabled the FortiGate will drop the SCTP traffic with RPF (Reverse Path Forwarding).
Technical Tip: Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing
The same result is also in the debug output:
FGT-FLO (sig_sigext) # 2024-09-10 12:20:34 id=20085 trace_id=1333 func=print_pkt_detail line=5822 msg="vd-sig_sigext:0 received a packet(proto=132, 194.24.145.1:2270->172.18.148.125:3868) from sig2. " <<-----
2024-09-10 12:20:34 id=20085 trace_id=1333 func=vf_ip_route_input_common line=2615 msg="find a route: flag=00000000 gw-172.17.11.254 via sig1"
2024-09-10 12:20:34 id=20085 trace_id=1334 func=print_pkt_detail line=5822 msg="vd-sig_sigext:0 received a packet(proto=132, 194.24.145.1:2270->172.18.148.125:3868) from sig2. "
2024-09-10 12:20:34 id=20085 trace_id=1334 func=vf_ip_route_input_common line=2615 msg="find a route: flag=00000000 gw-172.17.11.254 via sig1"
2024-09-10 12:20:34 id=20085 trace_id=1335 func=print_pkt_detail line=5822 msg="vd-sig_sigext:0 received a packet(proto=132, 194.24.145.1:2270->172.18.148.125:3868) from sig2. "
2024-09-10 12:20:34 id=20085 trace_id=1335 func=vf_ip_route_input_common line=2615 msg="find a route: flag=00000000 gw-172.17.11.254 via sig1"
