Multiple default routes across multiple interfaces

[RedMt]

Hello,

I've an interesting routing situation at one of my facilities using a Fortigate 300D on firmware v5.2.10, and I'm hoping someone here can help me with it.

We recently set up a second ISP at this facility, and put it on its own interface on the firewall. Let's call these 2 ISP interfaces WAN1 and WAN2. LAN / production traffic comes in on another interface while Guest network traffic comes in on yet another interface. Let's call those interfaces LAN1 and GST1.

I want all traffic from GST1 to use a default route pointing over WAN2 for internet traffic, while LAN1 uses a default route pointing over WAN1 for its internet. Additionally, it would be ideal if LAN1 would failover to WAN1 if WAN2 goes down, with LAN1 receiving a guaranteed higher priority than GST1 traffic in that failover scenario. GST1 does not need to fail over if WAN1 goes down.

Is this possible? If so, how do I set this up? I've attempted using link health monitoring and policy-based routing to create multiple default routes but I must be missing something, as I've not been able to get it working. If I had to guess, it's because I'm missing something in the policy based routing setup. I've not used that before, while I use the link health monitor in multiple other facilities / firewalls.

Thanks in advance for any advice.

[RedMt]

Friendly bump

[tanr]

You can have two (or more) default static routes, but they must both have the *same* distance, but with different priorities.  That way they both stay in the routing table and the policy route can force you to one or the other interface.   Some documentation:   http://kb.fortinet.com/kb/viewContent.do?externalId=FD32103  http://kb.fortinet.com/kb/documentLink.do?externalID=FD36462  http://kb.fortinet.com/kb/documentLink.do?externalID=100116  

[MikePruett]

Priority of a route in FortiOS is the equivalent of "cost" on other devices. You can have as many default routes as you want and they have the same distance but varying priorities.

[RedMt]

I responded before seeing that there were multiple responses... I'll check that info out, thanks. 

[RedMt]

I don't think priority / cost will get me where I want, because my route preference changes based on source interface (though source IP would also work). 

I've thought that policy routing is what I want but I've not been able to get it working before. In my earlier testing I tried making policy routes as stand-alone configurations, without any kind of corresponding static routes. One of the examples tanr referenced showed that static routes were defined with equal priority, then the policy route was used to define what traffic will use those routes. If both static routes need to exist before a policy route can be used, then that's why I couldn't get policy routing before.

[tanr]

The static routes need to both exist and be in the routing table for the policy routes to work. To get this, you need routes with the same distance but different priorities.

This still allows you to completely define the routes that will be used based on source interface or source IP through policy routes.  You just need the framework of the static routes in the routing table for the policy routes to build on. Note that the policy routes are evaluated in order, so you need to have more specific policy routes at the top of the list.

I currently have multiple internal interfaces (and some specific subnets) that I route out through various WAN interfaces and through different route-based VPN interfaces using this method.  I'm doing this with 5.4.x, but I believe 5.2.x is similar.

[RedMt]

Thanks again for the info, tanr. Do you know if link health monitors will remove policy routes from the routing table, similar to how static routes are removed?

I'm scheduling a maintenance window to test this out, and I'll let everyone know how it works out. 

[tanr]

It may be a little different between 5.2 and 5.4, but I think the link health, as in:

    config sys link-monitor

        set srcintf "wan1"

just removes the static routes that use that interface from the routing table if it sees the interface is down.

Policy routes get evaluated before static routing, but only get applied if there is a matching static route for the output-device interface the policy route gives.  So once the link monitor removes a static route for that specific interface from the table the policy routes that would otherwise route to that interface fail to match.

At least that is my understanding.  Trying out some test scenarios is probably the best way to see how this works for your situation.