Technical Note: How the FortiGate behaves when asymmetric routing is enabled

[wogasawara]

Description

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).