Skip to main content
ddemland
ddemland
New Member
September 6, 2018
Question

Drop failover sessions when link comes back up

  • September 6, 2018
  • 3 replies
  • 21090 views

I have a 60D running 5.2.3. I have two WAN connections, one for all the VoIP and the other for all other data. The VoIP network moves all it traffic out the voice WAN and all other networks move data out the data WAN. If the voice WAN goes down then all the voice traffic is rerouted out the data WAN. When the voice WAN comes back up the traffic is rerouted back to the voice WAN. The same goes for the data WAN when it fails, it goes to the voice WAN then back to the data WAN when it comes back up. I have all this working as expected right now.

 

My problem is that when the WAN link is restored none of the failed over sessions are rerouted back to their proper interface until there is a new session created. This means that it is possible for traffic to be routed out the wrong interface for a long time. How do I get these fail over sessions to terminate and create new sessions going out the proper WAN interface when that WAN interface comes back up? I can do this with my Cisco router automatically, but I need to get this same behavior with the Fortigate.

 

Thank you in advance,

 

David

      3 replies

      Prab
      Prab
      New Member
      September 7, 2018

      ddemland wrote:

      I have a 60D running 5.2.3. I have two WAN connections, one for all the VoIP and the other for all other data. The VoIP network moves all it traffic out the voice WAN and all other networks move data out the data WAN. If the voice WAN goes down then all the voice traffic is rerouted out the data WAN. When the voice WAN comes back up the traffic is rerouted back to the voice WAN. The same goes for the data WAN when it fails, it goes to the voice WAN then back to the data WAN when it comes back up. I have all this working as expected right now.

       

      My problem is that when the WAN link is restored none of the failed over sessions are rerouted back to their proper interface until there is a new session created. This means that it is possible for traffic to be routed out the wrong interface for a long time. How do I get these fail over sessions to terminate and create new sessions going out the proper WAN interface when that WAN interface comes back up? I can do this with my Cisco router automatically, but I need to get this same behavior with the Fortigate.

       

      Thank you in advance,

       

      David

      AFAIK: That's the deault behaviour in FGT.

      Once the session is created the FGT will keep using the same route for all the traffic for that session and does not perform a route lookup until the session is valid. (The FGT is offloading the session to NP, this improves the performance as FGT doesn't need to perform route lookups quite often.)

      Once the session expires, when ever a new packet arrives the FGT will perform a route lookup and in this case it will assign the exit interface accordingly.

       

      I would not recommend, but you could reduce the session life time or/and disable the offloading.

      Ref: http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-hardware-acceleration-52/acceleration-overview.htm#Network_processors_(NP1,_NP2,_NP3,_NP4,_NP4Lite,_NP6_and_NP6Lite)

       

      Hope it helps,

      Prab

      ddemland
      ddemlandAuthor
      New Member
      September 7, 2018

      Thank you for the information. However in most cases, that I have been exposed to, using two different connections are not only for fault tolerance but they also include cost differences and using one connection more often that expected incurs higher operation cost. I clearly understand the design and the reason for it, but not being able to restore normal operations quickly would lead to unexpected cost and other business operation issues.

       

      What would be nice is if I could write a script that runs when an interface comes back up where I could kill sessions that need to be moved back to the primary path so that they are moved back to their primary path as fast as possible and still leave the device working as closely as it can to its design. This would allow me to "interfere" only with routes that have to be restored after and outage. Is there a way to accomplish this task?

       

      Thank You,

       

      David

      Toshi_Esumi
      SuperUser
      Toshi_Esumi
      SuperUser
      September 7, 2018

      Voice would regularly be routed to one IP, SBC. I would try setting filter with the IP for source then destination of sessions to clear them "diag sys session clear".

      http://kb.fortinet.com/kb/documentLink.do?externalID=FD31635

      You might need to "clear" a couple of time to clear all of them.

      Toshi_Esumi
      SuperUser
      Toshi_Esumi
      SuperUser
      January 7, 2022

      I think "snat-route-change" was introduced with 6.0.

      But not clear your set up yet. You're now saying "both sites". So this is over two IPsec VPNs? Also the fail-over is controlled by Cisco behind FG60D?

      Whatever the case I recommend upgraded the 60D to the latest 6.0.x first.

      ellocodelacommencal
      ellocodelacommencal
      Visitor III
      January 7, 2022

      Hello,

      No, maybe I didn't make myself clear.
      I'm on version 6.4.7, so there is no problem.

      I have set up a performance SLA to our DataCenter via 2 ways, (IPsec tunnel & fibre optic). When the Fibre (main) goes down, the tunnel is up, but when it recovers the Firewall keeps the sessions and doesn't work correctly.

      The problem is that I don't have NAT configured in the rules, as it is "internal" communication and doesn't go out to the Internet.
      I don't want to add a SNAT to always have visibility of which is the correct source.

      Do you know of any way to proceed with this kind of errors?
      Maybe lowering the TTL?

      Thanks in advance!

       

       

      Toshi_Esumi
      SuperUser
      Toshi_Esumi
      SuperUser
      January 7, 2022

      First, it's not 60D if you can run 6.4.7. Must be either 60E or 60F.

      We use multiple IPSec VPNs and set up BGP to failover traffic into the tunnel for many customers. They're not NATed. But we don't have any "session stuck" issues for those cases. My assumption was the "session stuck" happens only when NAT is involved.

      I recommend you open a ticket at TAC to get it looked into.

        Terms & ConditionsAccessibility statement