Technical Tip: Using automation stitches to Enable/Disable IPV4 Firewall Policy based on SD-WAN logs

[jhelder]

Description	This article is a solution when there is an SD-WAN, and the user wants to allow the traffic to use only a specific link, when this link is down, the firewall should drop the packets instead of allowing them to go to the SD-WAN default policy. In this example, there is a VoIP subnet that should use the wan1 internet link, and when this link is down, the traffic should be dropped and not use the default SD-WAN policy. In this scenario, two automation stitches and two firewall policies will be used, but depending on the setup it is possible to accomplish the same with one stitch and one policy.
Scope	FortiGate, SD-WAN, Automation stitches.
Solution	In order to achieve this objective, it will be necessary to implement two distinct firewall policies and two automation stitches. It is presumed that the SD-WAN configuration has already been completed. Set two IPv4 firewall policies. The first one to block the traffic coming from the VoIP subnet, and should be disabled by default, and the second to allow this traffic: Create two automation stitches, the first one will verify based on the SD-WAN logs when the wan1 link is down, and based on this, will enable the BlockVoIP policy. The configuration for the first stitch will be:  For the trigger, it is possible to select the Event (SD-WAN SLA information warning) and for the filters, it is possible to define the interface followed by the name and the new value that should be dead, as can be verified below: With this configuration, every time the SD-WAN interface is down will trigger this stitch. It is now necessary to define the action, that should enable the policy BlockVoIP, which in this scenario is policy id 1 and this policy should always come before that the policy allows. To enable this policy, it is possible to utilize a script by navigating to the 'Add Action' section and selecting the 'CLI Script' option. From there, a new script can be created: And this is the stitch in the end: The configuration for the second stitch will be:  Another automation stitch will be needed to verify when the wan1 link is operating/up again and to disable the BlockVoIP policy. The trigger for this automation stitch will be the Event 'SD-WAN SLA notification', the filters will be the same interface and new value, but the new value key will be alive because it is wanted to verify that the link is back: And just create a new action the same way done before, but this one will disable the policy:   Depending on the policy setup, it is possible to accomplish the same thing just with one automation stitch that disables the policy that allows this traffic, so the traffic will match the default deny implicitly.