Tag Archives: SD-WAN

Fortigate – Separate IP pools out of multiple SDWAN Interfaces

1 Comment Posted by on October 1, 2024

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.

  1. Create SDWAN
  2. Create SDWAN rules send traffic out of needed interfaces.
  3. Next create the IP pools, and in CLI set the associated interface.
  4. 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.

The below shows the IP Pool option:

Below shows the Images for the firewall policy.

Fortigate , ,

Fortinet LDAP/RADIUS Source address with SD-WAN setup

Leave a comment Posted by on June 21, 2023

I found this a neat tidbit of knowledge that I thought I should share.

Created a Fortinet SDWAN setup with many sites – works awesome. Fortinet’s SDWAN is simple, but very effective with some really cool features to help with SLAs.

During this setup, I have Radius, and LDAP servers located across one of the members of the SDWAN (An IPSEC tunnel). As before with tunnels, you would modify the source address in CLI for the destination server. This would make sure requests originate from the interface you are expecting, and will go through the tunnel.

After switching the tunnel to be a member of a SDWAN interface the LDAP/RADIUS requests stopped working. I found another command was needed. This command is needed not only for Radius, and LDAP but also for FAZ, Fortiguard, and dns.

In CLI of both Radius and LDAP servers you will see these options:

The trick here is to set the “interface-select-method” to sdwan. This resolved my issue and allowed things to start working. The reason it does this is that Self-originating traffic, such as Syslog, FortiAnalyzer logging, FortiGuard services, remote authentication, and others, relies on routing table lookups to determine the egress interface that is used to initiate the connection. Policy routes generated by SD-WAN rules do not apply to this traffic.

Fortigate , , , , ,