Technical Tip: How to avoid specific traffic matching the wrong SD-WAN rule

In the Fortinet SD-WAN implementation, the same type of traffic could be matched by different SD-WAN rules at different times, without configuration changes in the middle.

There are two common reasons for this behavior:

• Interfaces are down.
• Interface is up, but the Performance SLAs probe is failing.

Some types of traffic must be checked only against a specific set of rules; this article explains how to do so.

For example, consider an example Fortinet SD-WAN deployment:

• Spokes with DIA (Direct Internet Access). 
• VPN IPSec tunnels between Spokes and Hubs with BGP over them, used for Private (Corporate) traffic.
• HTTP/HTTPS Internet Web traffic sent to an inspection/proxy infrastructure.
• The rest of the internet traffic is sent with default routes to the ISP's routers.

The spokes' SD-WAN rules are as follows:

config system sdwan

    config service

        edit 1

            set name "Traffic_to_Hubs"

            set mode sla

            set dst "RFC1918"

                config sla

                    edit "To_Hub_1"

                        set id 1

                    next

                end

            set priority-zone "Overlay"

        next

        edit 4

            set name "Web_traffic_to_SSE_POPs"

            set mode sla

            set src "all"

            set internet-service enable

            set internet-service-app-ctrl 15893 40568

                config sla

                    edit "TO_SSE_POP_1"

                        set id 1

                    next

                    edit "TO_SSE_POP_2"

                        set id 1

                    next

               end

           set priority-zone "GRE_Zone"

     next

     edit 3

         set name "Traffic_to_Internet_DIA"

         set mode sla

         set dst "all"

         set priority-zone "Underlay"

     next

end

If the Performance SLA checks fail over all SD-WAN members of the SD-WAN zone called 'Overlay' (VPN IPsec tunnels) due to Underlay degradation or Hubs unavailability, Private Web traffic could be matched by rule ID 4 and sent to the SSE (Security Service Edge) provider infrastructure.

To avoid this, it is necessary for private traffic not match default routes when there are no better routes available.

Preventing private traffic from matching default routes:

• Configure blackhole routes using administrative distance 254 for the 3 RFC1918 subnets: 10.0.0.0/8, 172.16.0.0/12, and 192.168.16.0/24, see the article Technical Tip: Use of Black hole route in site to site IPsec VPN scenarios.
• (Optional) Configure summary static routes with an administrative distance higher than BGP routes and lower than 254 for the VPN tunnel interfaces. This allows private network traffic to be sent over VPN tunnels if there is no better interface, even if the BGP peer is down.

In more complicated SD-WAN environments, it is recommended to also avoid use of the 'all' address for public addresses by using RFC1918 subnets as the destination and enabling dst-negate. This is frequently done as a best practice for SD-WAN rules handling internet traffic. However, note that preventing an SD-WAN rule match does not prevent traffic from egressing on an unintended interface if no active SD-WAN rule matches the traffic.

config firewall address

    edit "n-10.0.0.0/8"

        set subnet 10.0.0.0 255.0.0.0

    next

    edit "n-172.16.0.0/12"

        set subnet 172.16.0.0 255.240.0.0

    next

    edit "n-192.168.0.0/16"

        set subnet 192.168.0.0 255.255.0.0

    next

end

config firewall addrgrp

    edit "RFC1918"

        set member "n-10.0.0.0/8" "n-172.16.0.0/12" "n-192.168.0.0/16"

    next

end

config system sdwan

    config service

        edit 3

            set name "Traffic_to_Internet_DIA"

            set dst "RFC1918"

            set dst-negate enable

            set priority-zone "Underlay"

            set comment "No Corp traffic to Internet"

        next

end

Important notes:

Duplicate blackhole or 'backup' static routes are not visible in the routing table until BGP is UP. It is necessary to view the routing database with the following command to see them:

get router info routing-table database

After any SD-WAN configuration changes like the one described above, it is still possible to observe traffic matched by the wrong SD-WAN rules, for different reasons such as:

• Existing sessions never expire: to resolve this scenario, filter and clear the affected sessions. See 

  Technical Tip: Using filters to clear sessions on a FortiGate in the CLI.

• Configure a Preserve Route or Source NAT. See Technical Tip: Interface Stickiness for SD-WAN.