Technical Tip: Application control does not steer the traffic according to SD-WAN policy

[anikolov]

Description	This article describes how to fix an issue on the FortiGate when Application control does not steer the traffic according to sd-wan policy
Scope	FortiGate, SD-WAN, Application control.
Solution	This article describes how to deal with the unexpected behavior of a FortiGate, using an Application control, not being accordingly switched to the appropriate interface. In the given example below, the Youtube traffic is routed through interface port9, while the whole traffic goes through interface port9. The YouTube traffic is identified with application control. The firewall policy uses application control with deep inspection. The example with which this case study is observed is with the IP 173.194.10.135. This is a page on YouTube. At point 07:20:08 the traffic is being inspected and identified as HTTPS as an application, which sorts the traffic through SDWAN policy #3. Before initiating the traffic the app control list is blank: chen-esx22 # diagnose sys sdwan internet-service-app-ctrl-list List App Ctrl Database Entry(IPv4) in Kernel. The session list: session info: proto=6 proto_state=11 duration=5 expire=3597 timeout=3600 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper= class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0 state=log may_dirty ndr f00 app_valid log-start statistic(bytes/packets/allow_err): org=52043/874/1 reply=2258933/1735/1 tuples=3 tx speed(Bps/kbps): 7704/61 rx speed(Bps/kbps): 393543/3148 orgin->sink: org pre->post, reply pre->post dev=9->12/12->9 gwy=192.168.177.1/0.0.0.0 hook=post dir=org act=snat 192.168.185.111:57094->173.194.10.135:443(192.168.177.2:57094) hook=pre dir=reply act=dnat 173.194.10.135:443->192.168.177.2:57094(192.168.185.111:57094) hook=post dir=reply act=noop 173.194.10.135:443->192.168.185.111:57094(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=4 pol_uuid_idx=15851 auth_info=0 chk_client_info=0 vd=0 serial=00000326 tos=ff/ff app_list=2000 app=38569 url_cat=0 sdwan_mbr_seq=1 sdwan_service_id=3 <-------- non critical traffic  rpdb_link_id=ff000003 ngfwid=n/a npu_state=0x001101 no_offload no_ofld_reason: disabled-by-policy redir-to-ips denied-by-nturbo At 07:20:41, the traffic starts to use the appropriate interface. The output of the identified applications is below: chen-esx22 # diagnose sys sdwan internet-service-app-ctrl-list List App Ctrl Database Entry(IPv4) in Kernel: YouTube(31077 5): IP=142.251.36.86 6 443 YouTube(31077 5): IP=142.251.36.129 6 443 YouTube_Channel.ID(44956 5): IP=142.251.37.110 6 443 YouTube_Video.Play(38569 5): IP=172.217.130.70 6 443 YouTube_Video.Play(38569 5): IP=173.194.10.135 6 443 <----- the IP that is used in the example. The ID is 38569. YouTube(31077 5): IP=173.194.10.138 6 443 YouTube_Video.Play(38569 5): IP=173.194.191.232 6 443 The session:  session info: proto=6 proto_state=11 duration=4 expire=3598 timeout=3600 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper= class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0 state=log may_dirty ndr f00 app_valid log-start statistic(bytes/packets/allow_err): org=27998/434/1 reply=1152377/855/1 tuples=3 tx speed(Bps/kbps): 190/1 rx speed(Bps/kbps): 1224/9 orgin->sink: org pre->post, reply pre->post dev=9->5/5->9 gwy=192.168.178.1/0.0.0.0 hook=post dir=org act=snat 192.168.185.111:57102->173.194.10.135:443(192.168.178.2:57102) hook=pre dir=reply act=dnat 173.194.10.135:443->192.168.178.2:57102(192.168.185.111:57102) hook=post dir=reply act=noop 173.194.10.135:443->192.168.185.111:57102(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 policy_id=4 pol_uuid_idx=15851 auth_info=0 chk_client_info=0 vd=0 serial=00000336 tos=ff/ff app_list=2000 app=38569 url_cat=0 <----- Application ID 38569. sdwan_mbr_seq=2 sdwan_service_id=2  <----- The traffic switched to the Youtube SD-WAN policy. rpdb_link_id=ff000002 ngfwid=n/a npu_state=0x001101 no_offload no_ofld_reason: disabled-by-policy redir-to-ips denied-by-nturbo If the bandwidth on the SD-WAN bandwidth monitoring is observed right after the traffic is initiated, the traffic would appear to go through the SD-WAN member 1, as this session will remain open. At first, when the session was opened, this traffic was identified as HTTPS and marked for SD-WAN policy #3. After the IPS engine identified that this traffic is Youtube_Video_Play, the new sessions that opened are marked that should go through the SD-WAN policy #2. If the first session list is examined again, it can be noticed that the application is identified already as 38569, but it is still using the SD-WAN policy #3 instead of #2. This is the expected behavior, for the first session which observed the traffic, the interface remains the same. To change this behavior, the following changes should be made: set snat-route-change enable <----- Using-SNAT-route-change set ippool enable <----- Use-of-IPPool-to-NAT-traffic-with-a-different-IP