Description |
This article provides a solution when the Traffic Shaper Policy is configured with specific sources and as a destination multiply ISDBs. |
Scope | FortiGate. |
Solution |
When configuring a Traffic Shaper Policy with Application Category, URL Filter Category, and multiplying ISDBs as a destination, the Traffic Shaper Rule will not be matched and the traffic is not dropped, even though the bandwidth is limited.
In the below example, the Traffic Shaper Policy is configured with multiple ISDBs as destination, Application Category, and URL Filter Category
Then, the Traffic Shaper profile is applied to the Shaper Policy (in this lab Per-IP Shaper is used):
Per-IP Shaper configuration is as per below :
Configuration on the CLI is as per below :
config firewall shaping-policy edit 4 set uuid 480b4d46-8fa7-51ef-1f0a-f5ffb87b87a1 set name "TEST Without URL" set internet-service enable set internet-service-name "Adobe-Adobe.Sign" "Adobe-Adobe.Experience.Cloud" "Adobe-DNS" "Adobe-FTP" "Adobe-ICMP" "Adobe-Inbound_Email" "Adobe-LDAP" "Adobe-NetBIOS.Name.Service" "Adobe-NetBIOS.Session.Service" "Adobe-NTP" "Adobe-Other" "Adobe-Outbound_Email" "Adobe-RTMP" "Adobe-SSH" "Adobe-Web" <<<<<< Multiply ISDB as destination set app-category 29 30 28 21 8 12 31 15 26 2 6 7 23 22 32 17 5 3 25 <<<<< Application Category set url-category 50 52 <<<<< URL Category set srcintf "internal1" set dstintf "TX - SDWAN" set per-ip-shaper "TEST" set srcaddr "all" next end
When testing Adobe or another ISDB, the traffic is not being dropped and is allowed, although on the Shaper the bandwidth is limited. This can happen because the generated traffic should match the ISDBs, the Application Control, and also the URL Category. For the above-explained configuration, the traffic shaping works as expected for Adobe traffic.
FGR60F-4 # diagnose sys session list session info: proto=6 proto_state=11 duration=29 expire=3589 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper=TEST class_id=0 shaping_policy_id=4 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255 state=log may_dirty per_ip ndr npu f00 app_valid url_cat_valid statistic(bytes/packets/allow_err): org=2529/18/1 reply=12407/18/1 tuples=3 tx speed(Bps/kbps): 86/0 rx speed(Bps/kbps): 423/3 orgin->sink: org pre->post, reply pre->post dev=7->6/6->7 gwy=x.x.x.x/y hook=post dir=org act=snat x.x.x.x hook=pre dir=reply act=dnat x.x.x.x hook=post dir=reply act=noop 3.x.x.x.x pos/(before,after) 0/(0,0), 0/(0,0) src_mac=00:67:72:61:1e:01 misc=0 policy_id=1 pol_uuid_idx=616 auth_info=0 chk_client_info=0 vd=0 serial=000307e0 tos=ff/ff app_list=2000 app=34050 url_cat=52 sdwan_mbr_seq=5 sdwan_service_id=3 rpdb_link_id=ff000003 ngfwid=n/a npu_state=0x003c94 ips_offload ofld-O ofld-R npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000 vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0 no_ofld_reason: total session 100
Conclusion: ISDB and application Control might match, but if the URL Category does not match, traffic shaping will not be applied. It is enough that one of the three above conditions is not met, and the generated traffic will not match the Shaper policy. |