Copying the DSCP value from the session original direction to its reply direction

In an SD-WAN scenario when DSCP tags are used to mark traffic from the spoke to the hub, it is sometimes desirable for the hub to mark the reply traffic with the same DSSP tags. The diffserv-copy setting in firewall policy configurations allows the DSCP tag to be copied to the reply direction.

config firewall policy
    edit <id>
        set diffserv-copy {enable | disable}
    next
end

Example

The use cases in this example are for a hub and spoke SD-WAN deployment. Traffic from the spoke (either real traffic or SLA health check probes) can be marked with a certain DSCP tag when leaving the spoke. QoS may be applied by an upstream device based on the DSCP tag. When the traffic arrives on the hub, the hub may also want to mark the reply traffic to the spoke with the same DSCP tag. This would allow QoS to be applied to the traffic in the reply direction as well, which is traffic in the hub to spoke direction associated with the same session in the spoke to hub direction.

While this topology simplifies the SD-WAN deployment into a single hub and spoke, this feature applies to the following configurations:

• Multiple spokes (branch sites)
• One or more hubs (data center sites)
• Multiple overlays connecting spokes to hubs
• SD-WAN configured on spokes to pick the best overlay

Use case 1: typical forwarding traffic

Traffic originates from the spoke and is destined for a server behind the hub. The spoke marks the traffic with a DSCP tag of 101010. This is done by enabling diffserv-foward on the spoke firewall policy. It can also be accomplished by enabling dscp-forward in an SD-WAN rule.

The hub allows the traffic in through a firewall policy. By enabling diffserv-copy on the firewall policy, it will mark the reply traffic on the corresponding sessions with the same DSCP tag in which it came.

To configure the FortiGates:

1. Configure the firewall policy on the spoke (FortiGate A):

   config firewall policy
       edit 1
           set srcintf "port1"
           set dstintf "virtual-wan-link"
           set action accept
           set srcaddr "all"
           set dstaddr "all"
           set srcaddr6 "all6"
           set dstaddr6 "all6"
           set schedule "always"
           set service "ALL"
           set logtraffic all
           set nat enable
           set diffserv-forward enable
           set diffservcode-forward 101010
       next
   end

2. Configure the firewall policy on the hub (FortiGate B):

   config firewall policy
       edit 3
           set srcintf "virtual-wan-link"
           set dstintf "wan1"
           set action accept
           set srcaddr "all"
           set dstaddr "all"
           set srcaddr6 "all"
           set dstaddr6 "all"
           set schedule "always"
           set service "ALL"
           set logtraffic all
           set auto-asic-offload disable
           set nat enable
           set diffserv-copy enable
       next
   end

To test the configuration:

1. Generate some forwarding traffic.

2. Verify that the session’s tos value from the original direction is applied to the reply direction:

   # diagnose sys session filter policy 3
   # diagnose sys session filter dst 172.16.200.55
   # diagnose sys session list
   
   session info: proto=1 proto_state=00 duration=35 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
   origin-shaper=
   reply-shaper=
   per_ip_shaper=
   class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
   state=log may_dirty f00 
   statistic(bytes/packets/allow_err): org=3024/36/1 reply=3024/36/1 tuples=2
   tx speed(Bps/kbps): 82/0 rx speed(Bps/kbps): 82/0
   orgin->sink: org pre->post, reply pre->post dev=20->17/17->20 gwy=172.16.200.55/10.2.2.1
   hook=post dir=org act=snat 10.2.2.1:25290->172.16.200.55:8(172.16.200.2:25290)
   hook=pre dir=reply act=dnat 172.16.200.55:25290->172.16.200.2:0(10.2.2.1:25290)
   misc=0 policy_id=3 pol_uuid_idx=1097 auth_info=0 chk_client_info=0 vd=3
   serial=0000a018 tos=6a/6a app_list=0 app=0 url_cat=0
   rpdb_link_id=00000000 ngfwid=n/a
   npu_state=0x4000001 no_offload
   no_ofld_reason:  disabled-by-policy
   total session 1

Use case 2: local-in traffic destined to a loopback interface

SLA health checks from the spoke are destined for a loopback interface on the hub. The health check is marked with a DSCP tag of 000001 by the spoke. When the hub receives the probes to its loopback, it will mark the replies with the same DSCP tags in which it came.

To configure the FortiGates:

1. Configure the health check on the spoke (FortiGate A):

   config system sdwan
       config health-check
           edit "ping"
               set server "1.1.1.1"
               set diffservcode 000001
           set members 0
       next
   end

2. Configure the loopback interface on the hub (FortiGate B):

   config system interface
       edit "loopback"
           set vdom "vdom1"
           set ip 1.1.1.1 255.255.255.255
           set allowaccess ping https ssh  http telnet 
           set type loopback
           set role lan
           set snmp-index 35
       next
   end

3. Configure the firewall policy on the hub:

   config firewall policy
       edit 1
           set srcintf "virtual-wan-link"
           set dstintf "loopback"
           set action accept
           set srcaddr "all"
           set dstaddr "all"
           set srcaddr6 "all"
           set dstaddr6 "all"
           set schedule "always"
           set service "ALL"
           set logtraffic all
           set auto-asic-offload disable
           set nat enable
           set diffserv-copy enable
       next
   end

To test the configuration:

1. Generate some local-in traffic.

2. Verify that the session’s tos value from the original direction is applied to the reply direction:

   # diagnose sys session list
   
   session info: proto=1 proto_state=00 duration=1 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
   origin-shaper=
   reply-shaper=
   per_ip_shaper=
   class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
   state=log local may_dirty 
   statistic(bytes/packets/allow_err): org=80/2/1 reply=80/2/1 tuples=2
   tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
   orgin->sink: org pre->in, reply out->post dev=20->42/42->20 gwy=1.1.1.1/0.0.0.0
   hook=pre dir=org act=noop 10.2.2.1:15->1.1.1.1:8(0.0.0.0:0)
   hook=post dir=reply act=noop 1.1.1.1:15->10.2.2.1:0(0.0.0.0:0)
   misc=0 policy_id=1 pol_uuid_idx=0 auth_info=0 chk_client_info=0 vd=3
   serial=0001a846 tos=41/41 app_list=0 app=0 url_cat=0
   rpdb_link_id=00000000 ngfwid=n/a
   npu_state=0x000001 no_offload
   no_ofld_reason:  local disabled-by-policy
   total session 1

   Capture packets can also be used verify that the DSCP value from the original direction is applied to the reply direction.