Setting up and managing 2 WAN links

[RotaryISD]

Hi,

I'm new to Fortigate and we are currently migrating from Cisco ASA to Fortigate FG201 (v7.0.5). 

From our existing setup, we have 2 different WAN links (2 diff ISPs).

ISP 1 is used as primary gateway for internet and ISP 2 is for VPN connection (IPsec/SSL VPN). ISP2 also serves as a backup link for internet traffic (manual failover). We are also using Zscaler Proxy, so we have a FW policy that direct all internet traffic to Zscaler.

My question is how can we achieve the similar setup with our new Fortigate FW? or what is the best way to achieve this?

I've been doing some reading on Fortigate but I'm still not sure what is the best way or option to do this.

I read from this KB that it can be done using the legacy method but not sure if we should use option 1 or 3 for this.

https://docs.fortinet.com/document/fortigate/7.0.5/administration-guide/360563/dual-internet-connect...

or via the SDWAN features.

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/19246/sd-wan

Can't figure out which is best suited for our requirement.

Another thing is the NAT requirements. Is it better to use the Central NAT or do it on the per policy basis?

One scenario is for our internal network, example 192.168.1.0/24 (user VLAN). For internet traffic its primary gateway will be isp1 and only goes to ISP2 if ISP1 link fails. How is the NAT going to be for this? Do I need to create 2 separate NAT entry in Central NAT to NAT 192.168.1.0/24 to each of the outgoing interfaces of the 2 ISP? or just create 2 FW policies such as below:

Internal --> ISP1

192.168.1.0/24 --> Any and NAT to outgoing interface (ISP1)

Internal --> ISP2

192.168.1.0/24 --> Any and NAT to outgoing interface (ISP2)

Or is it better to create a Zone to group the 2 WAN ports and create the policy based on that?

How about those with 1 to 1 static NAT? We only have 1 public IP range/pool available which is from ISP2. Will it still work if the traffic is going out to ISP1? Coz i read from this article https://www.fortinetguru.com/2017/11/ip-pools/ that says there is a limitation when using IP pools such as if the IP address(es) within the pool are different from the IP address(es) that are assigned to the interface communications based on those IP addresses will fail.

Appreciate your input and thank you in advance. :)

[Toshi_Esumi]

The difference between Scenario1 and Scenario3 is

- With Scenario1, you can't take VPNs on the secondary interface because the default route toward the secondary won't be in the routing-table unless the primary goes down and the primary default route is removed by the link-monitor. So the returning traffic would try to go out through the primary but would be dropped due to "asymmetric routing".

- With Scenario3, both default routes are in the routing-table with different priority so out-to-in initiated traffic like VPNs works because the FGT routes returning traffic to the same interface that came in.

The next my comment might not be 100% correct because my insight of SD-WAN's mechanism is not so deep. You might want to wait more answers from others. But my understanding of SD-WAN is it has same distance default routes to all Internet candidates and SD-WAN rules (conditional priority routes) decide which one to be chosen based on the criteria you set for the specific traffic and link health (packet loss, latency and jitter).

Of course you can set the default behavior when traffic doesn't much any rules to make the primary primary if you want instead of load balancing.

So it's more flexible but that means you need to configure the rules to make the routing decision behavior as you want.

Central NAT vs. NAT on policies are more personal preference, or previous experiences with different platform. But if you ask me my preference, I wouldn't go to central NAT because to me the config of C-NAT to specify the traffic is duplicated with policies most of cases. I'm too lazy to do that.

NAT works based on the conditions in the policy. So unrelated or separated from routing decision. You generally have to have two different NAT policies one for ISP1 and one for ISP2. It's not based only on source interface. Unless you combine those wan interfaces together into a "zone" then let the FGT pick what is the NAT outside IP. Just remember if you use zone, you can't create specific/different policies for wan1 and wan2. So in your case, when it's not simple failover, you can't use a zone.

You can't use ISP2's public IPs as source IP when you send packets out to ISP1. If you do that returning packets still come back to wan2 as long as the circuit is up (otherwise never come back), which is another way of "asymmetric routeing" and the FGT would drop those returning packets.

Toshi

[RotaryISD]

Hi Toshi,

Thanks for the advise. 

About what you said on Scenario1, that we can't take VPN on the secondary ISP interface because the default route for the secondary wont be in the routing table. Are you referring to SSLVPN (remote user) traffic or IPsec or for both? I understand the secondary default route wont be in the routing table, but how about if we configure a specific static route for the IPsec connection towards the secondary ISP link? will it still not work?

As for the NAT, i guess you are right its more of personal preference between CNAT and policy based NAT. 

Just to make sure I understand correctly what you said that I can't use the ISP2 public IP as source IP to go out ISP1. 

Say I have a static private IP address of 192.168.1.10/24 (user vlan) assigned to my workstation and i assigned a static public IP address of 172.10.10.10 (from ISP2) to it to go out to internet, but because the default internet gateway is via ISP1, it wont work as the packets will be drop? Is there any workaround for this?

[Toshi_Esumi]

Of course it works if specific routes are going to the secondary like for site-to-site or specific dialup source if it's static. Just need to have proper routes toward the interface.

And if you put the ISP2's IP in ippool to use the outside NAT IP for the primary interface, it of course goes out. The problem is its returning. Packets back from the destination to 172.10.10.10 would come back to the secondary because that IP belongs to ISP2,never to ISP1. At that time the FGT drops it because of "asymmetric".

[RotaryISD]

Hi Toshi,

I see. Do you have an idea of a workaround on this or how to mitigate this aside from enabling the asymroute option in FGT? Will scenario 3 be able to solve this? Redundancy and load balancing option? Or maybe creating a Zone for the 2 ISP interface? Though I understand when you use a Zone, you cant create a separate policy for the Zone members.

Thanks for your responses btw. You've been very helpful. :)

[Toshi_Esumi]

No. Probably any other decent FWs would behave the same. Otherwise it would allow spoofing. If you want to do like that, either you need to have your own IP subnet with BGP ASN and advertise it to both ISP1 and 2, or set a L3 route in front of the FGT and let the router handle the routing, which doesn't care sessions and asymm routing. SD-WAN might be able to do something but I doubt.

Toshi

[RotaryISD]

Hi Toshi,

hmmm. I'm thinking of forcing the traffic of those endpoint that has the public IP NAT of ISP2 to use ISP2 as their default gateway by creating PBR. not sure though whether that would work.