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 |
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.
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.
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. If it requires to only scheduling a Firewall policy disable once a week or daily below script:
For instance below automation script helps schedule disabling firewall policy daily at 3:00 pm and enabling back at 3:05pm .
Create schedule trigger:
Disabling Firewall policy:
config system automation-trigger
Enabling firewall policy:
config system automation-trigger
Create a CLI script for action:
config system automation-action
config firewall policy
Disable firewall policy:
config system automation-action
config firewall policy
Create Automation stitch using the trigger and action created earlier: Disabling firewall policy:
config system automation-stitch
Enabling firewall policy :
config system automation-stitch
config actions |