De-configuring Dual WAN Load Balancing advice

[3pointD]

Hello,

I've been running dual wan connections using ECMP Weighted Load Balance on my FWF80CM (v4 MR3 Patch 15) for a couple of years now. The solution has worked out pretty well but now I want to change this design to a more manual setup to improve control over how traffic flows through the device.

My goals:

WAN2 - Primary Gateway

WAN1 - Failover Gateway

Needs:

I will still need to Policy route some specific traffic out WAN1

I will still need to access VIPs setup on WAN1 externally

I will still need to access HTTPS admin on WAN1 externally

To start off I assumed that I could just change ECMP back to Source IP (default) and then give WAN1 administrative distance higher than WAN2. Both WAN1 and WAN2 have static routes with the same distance currently. When I did this working remotely over HTTPS on WAN1 as soon as I applied the Admin Distance on WAN1 I lost my remote connection and found that I was also unable to access HTTPS admin on WAN2. In addition when I arrived at the office HTTP/HTTPS traffic was not working. I could ping external addresses (I think) but DNS wouldn't resolve. After changing the Distance back to 0 on both interfaces and a reboot of the fortigate HTTP/HTTPS started to flow again.

I have an internal DNS server and do not use the fortigate. Can anyone tell me what might have happened. Do I need to clear the routing table or cache after changing these settings? Should I be using Priority instead of Distance? How did this affect my inbound HTTPS admin session? How does this affect inbound external traffic?

I don't know a whole lot about routing aside from what I've read in the fortigate manual and here in the forums so be gentle.

Thanks 

[obfuscated · Accepted solution]

The distance variable dictates what routes go into the routing table and only the best (or the equal best in the case of ECMP) will go into the routing table.  By changing this you have removed one of the routes.

The Priority is the next consideration so if there are multiple routes in the routing table (ie same distance) it will use the priority to select which one it chooses to send traffic to.

Then we are down to the load balancing of the ECMP ie based on source address or a weighting.

I am not sure what version you are using but version 5.2 has a 'WAN link interface' feature which allows you to more easily bundle the interfaces and may be worth exploring:-

http://www.google.co.uk/u...;bvm=bv.96041959,d.ZGU

[3pointD]

Hi just wanted to check back in and update on how I resolved the issue even though it is quite embarrassing.

My problem was that I had not setup a policy to allow my DNS servers through WAN2. I could not believe it! How did I miss that? It was one of the most basic requirements of the process. Learned a big lesson on this one.

Thanks obfuscated for your efforts. I appreciate it!!

[3pointD]

All,

I've completed what I've set out to do which was to de-configure my weighted load balancing setup on my dual WAN FWF-80CW. So far everything is working the way I wanted but I have a couple of questions on some things I ran across in the process.

Firstly why don't the connected routes work if you create a Routing Policy? If I setup the following Routing Policy no devices on INT1 can communicate with any other interface except WAN1. Is it because the Policy matches so the router doesn't look further i.e. the routing table?

Policy Example:

Inbound: INT1

Src: 10.0.0.0/24

Dst: 0.0.0.0

Outbound: WAN1

Gateway: 0.0.0.0

Also this may be related. I found that in order to allow a device on an Internal interface to communicate with an external VIP on another I had to create a Routing Policy explicitly pointing that Internal interface to the other Internal interface that the VIP points to. Why would I need to do this when I'm trying to reach a public VIP? I'm assuming it's because all of the interfaces are on the same router so it doesn't use the same paths for these connections as opposed to those coming in from an external gateway.

Hopefully my questions make sense. Thanks!