Skip to main content
m9679
m9679
New Member
March 5, 2020
Question

Policy routing with automatic failover (or alternative)

  • March 5, 2020
  • 1 reply
  • 7350 views

This is an architecture/design/capability question.

 

Design Requirements:

[ul]
  • Some LAN networks need to be routed to the internet via Path-A during normal conditions, and via Path-B if Path-A is not available
  • Inbound-initiated traffic to/via the WAN port (via Path-B) continues to work in all conditions[/ul]

        Approaches, Questions:

    [ul]
  • Policy routes for the relevant LAN networks [ul]
  • Good [ul]
  • Works fine in normal routing conditions[/ul]
  • Bad [ul]
  • Not aware of how to make a policy route auto fail over to secondary path when the primary path is down (eg link-monitor)[/ul]
  • Question [ul]
  • Is there a way to achieve failover (not load-balancing) with policy routes?[/ul][/ul]
  • Static default route [ul]
  • Good [ul]
  • Can apply a link-monitor to achieve default route failover to Path-B[/ul]
  • Bad [ul]
  • Inbound traffic to the WAN port is not returned (eg via session table matching) back out the WAN port (ie is dragged back out Path-A in normal routing conditions)[/ul]
  • Question [ul]
  • Isn't the session table supposed to match the reply traffic and override the routing table, dragging the reply traffic back out the WAN?  I know - not true in normal switching and routing, but we have been told by a Fortinet SE (at least we had understood) that the session table overrides the routing table for reply packets that match an existing session, and therefore reply packets will get routed back out the WAN interface.  We were counting on that to be true for this inbound-initiated traffic.  Doesn't seem to be the case.[/ul][/ul][/ul]

     

    • 1 reply

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    March 6, 2020

    You might have attached an image, which seems to be broken.

    My guess is only way to accomplish is to set up SD-WAN including two paths and tweak the rules. Once you configured a policy route, it won't disappear when the circuit goes down because it's a "policy" not a "route". So won't fail-over.

    Sessions could override but the route still needs to be there toward the interface you're steering traffic to. That's why SD-WAN set default-route to all member interfaces. And static route's "priority" works in the way you described because all static routes for the same prefix/prefix-length with different priorities co-exist in the routing-table. Only sessions initiated by inside follow the highest priority route.

     

    You can ask the SE further.

    m9679
    m9679Author
    New Member
    March 6, 2020

    Thanks.  Yes we are looking more closely at how SD-WAN configurations might help, but we still have the problem of inbound-initiated sessions via the WAN interface.  What we see is that the replies from those are picked up by the policy/static routes that have dst=0.0.0.0/0.  We're expecting those inbound-initiated sessions to have their replies picked up by the session table, instead of the routing table, but evidence so far is they are not (the policy/routing table is winning, and those replies get dropped by RPF).

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    March 6, 2020

    Now I see your diagram. Is the both that decides 'A' or 'B' actually a FortiGate? You used FortiGate's icon at the box on 'A' path, but didn't use it for the key box.

    Terms & ConditionsAccessibility statement