Now that I setup SD-WAN interfaces in Fortigate for almost any deployment – due to future proofing. I have struggled with how to make internal resources that need to nat out publicly from a certain IP (Not on the interface). In a normal scenario, no problem, we just use an IP pool for outbound traffic from that internal device(s). In the SD-WAN scenario, I had a problem where the outbound IP Pool for the outgoing nat would still try to hide the IP behind a IP that lived on the WAN that is having the outage. The firewall policy seemed not to be smart enough to say – “ahh that interface is down, lets make sure it goes out of policy 2”. One option I did was have two policies – one to nat out of each ISP, then to have a automation stitch to see the interface go down, and disable the normal policy, which would then hit the lower policy.
The option I am describing below is much better.
Within the IP pool there is an option within CLI to set an associated interface. This fixes the issues. So, I have two IP Pools, one for ISP 1, and the other for ISP 2. So to talk through the setups – there are a couple.
Create SDWAN
Create SDWAN rules send traffic out of needed interfaces.
Next create the IP pools, and in CLI set the associated interface.
Create a firewall policy matching the correct object, and add both IP pools in the IP pool list. The SDWAN rule will set with VIP is used based on SLA Method.
I’ve run into peculiar case with this. What about long-lived sessions? It’s fine as long as your SMTP server establishes a new session after SDWAN shifts traffic to different interface, but what about, say, cloudflared tunnel? The FortiGate does not seem to drop the session. Without the global snat-route-change parameter enabled, it will continue using the wrong NAT IP. But even with snat-route-change enabled, if it changes the SNAT IP in the middle of a session, the remote end would not agree to it and sessions hang.
I’ve run into peculiar case with this. What about long-lived sessions? It’s fine as long as your SMTP server establishes a new session after SDWAN shifts traffic to different interface, but what about, say, cloudflared tunnel? The FortiGate does not seem to drop the session. Without the global snat-route-change parameter enabled, it will continue using the wrong NAT IP. But even with snat-route-change enabled, if it changes the SNAT IP in the middle of a session, the remote end would not agree to it and sessions hang.