FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
This article is intended to explain 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 are unable to reach certain other networks. This can occur when request and response packets follow different paths and don't 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
Solution
When asymmetric routing is enabled, the firewall will globally behave as follows.
For TCP packets
1) If the packet is a 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).
2) 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).
3) If the packet is not a SYN and the session doesn't exist (asymmetric routing), then all packets are passed to the CPU and the FortiGate doesn't lookup 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 which only makes routing decision. 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 doesn't exist on the FortiGate, the ICMP reply will be routed if a route exists on the routing table without security inspection.
For UDP packets
UDP packet is checked by session table regardless of asymmetric routing. Asymmetric routing does not affect UDP packet. 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 point TCP point 3 and ICMP. However, the feature could be used in some cases where it is really required however, it is important to be aware of the constraints when the feature is enabled (no policy lookup and no UTM inspection).
