Hot!Site-to-site VPN doesn't works in faillover scenario

Author
pirgi
New Member
  • Total Posts : 2
  • Scores: 0
  • Reward points: 0
  • Joined: 2017/09/08 13:56:02
  • Status: offline
2017/09/09 09:59:06 (permalink)
0

Site-to-site VPN doesn't works in faillover scenario

Hi all, I wanna thanks for every advice you can get me.
I want use a Site-To-Site VPN in a failover scenario but the tunnel seem to be working only if the lines are up.
I try to describe the situation.
 
Head Office network LAN 192.168.8.0/24
fortigate ip on LAN 192.168.8.253
Primary Link MPLS, IP router 192.168.8.254 connected on FG internal interface
ADSL Internet Link is connected to WAN1 port of fortigate
I have configured a static route to branch office lan 192.168.4.0/24 - gataway 192.168.8.254 on port1 (internal)
 
Branch Office network 192.168.4.0/24
fortigate ip 192.168.4.253
Primary Link MPLS, IP router 192.168.4.254 connected on FG internal interface
ADSL Internet Link is connected to WAN1 port of fortigate
I have configured a static route 192.168.8.0 - gataway 192.168.4.254 on port 1 (internal)
 
in this condition a pc in the head office LAN with gataway 192.168.8.253 (fortigate) reaches a pc of the branch office LAN through MPLS using routers 192.168.8.254 without problems and vice versa.
 
Now I configured a SITE-TO-SITE VPN Tunnel between the two fortigates.
The Tunnel works fine, until the MPLS does not fall.
 
I have configured in the Branch Office Fortigate a monitor link (dead link detection use ping on 192.168.8.254 using gataway 192.168.4.254) . When the ping fails the static route on internal port are deleted from the routing table, as I expect.
In this case, the only active route to 192.168.8.0/24 network is the “TUNNEL Route”, so I expect the traffic flow through the tunnel towards the newtork head office, but this does not happen.
 
In conclusion, if the lines are all up and I manually change the priority of static routes, (privileging the “tunnel route”) the traffic passes through the tunnel correctly, but in case of failover of the MPLS link or in case of router MPLS dead, the packets do not pass through the tunnel, (despite the link monitor works fine) how is it possible?
 
Thank you in advance
post edited by pirgi - 2017/09/09 12:49:03
#1

3 Replies Related Threads

    Antonio Milanese
    Bronze Member
    • Total Posts : 52
    • Scores: 4
    • Reward points: 0
    • Joined: 2012/12/15 06:11:02
    • Status: offline
    Re: Site-to-site VPN doesn't works in faillover scenario 2017/09/11 06:21:28 (permalink)
    0
    Hi Pirgi,

    you must have link monitors probes on both sites or when, on HQ site, the mpls link fail since this is a transit network the route never be removed (no interface down evnt) effectively blackholing the HQ originated routed traffic.

    We have some customers with a similar setup and all it's working seamlessly..some quick suggestions:

    - set your floating routes as same distance different priority so the route it's already installed on the RIB with a little fast failover
    - set link-monitor source-ip as FGT mpls facing interface ip to bind reachability path

    Best regards,

    Antonio
    #2
    pirgi
    New Member
    • Total Posts : 2
    • Scores: 0
    • Reward points: 0
    • Joined: 2017/09/08 13:56:02
    • Status: offline
    Re: Site-to-site VPN doesn't works in faillover scenario 2017/09/12 06:39:29 (permalink)
    0
    Hi Antonio,
    thanks for your answer... I have configured the link monitor only in the Branch Office, when the MPLS falls down I tryed to manually change the priority of the static route configured in the HQ for redirect traffic throught the tunnel but nothing changes.
    The link monitor on the Branch Office works as I expected, according to the param
    set update-static-route enable
    all the static route associated to internal port are erased from the routing table and only the tunnel route remain active.
     
    I think the problem is routing.... and related sessions, but I haven't the solution yet.
    Now I focus on blackhole route for resolve the issue.

    In my case I have the same remote subnet can be reached by two alternative paths, but when one oh them die, I think that fortigate doesn't discard the previous sessione that use the old (down) path....

    Is it possible ? or I get the wrong end of the stick...
    Gianni



     
    #3
    Antonio Milanese
    Bronze Member
    • Total Posts : 52
    • Scores: 4
    • Reward points: 0
    • Joined: 2012/12/15 06:11:02
    • Status: offline
    Re: Site-to-site VPN doesn't works in faillover scenario 2017/09/12 12:09:35 (permalink)
    0
    Hi pirgi

    pirgi
    thanks for your answer... I have configured the link monitor only in the Branch Office, when the MPLS falls down I tryed to manually change the priority of the static route configured in the HQ for redirect traffic throught the tunnel but nothing changes.
    The link monitor on the Branch Office works as I expected, according to the param
    ....
    I think the problem is routing.... and related sessions, but I haven't the solution yet.
    Now I focus on blackhole route for resolve the issue.


    Assuming that you have all policy correctly in place and that the tunnel it's working...
    Yes you have to configure a link probe on HQ to determine whether the transit network path is working end-to-end and therefore will have to remove the now invalid route when the MPLS link fail.
    to be more explicit:

    #HQ#
    routes:
    192.168.4.0/24 via device PORT1 , gateway 192.168.8.254 , distance 5 priority 10
    192.168.4.0/24 via device VPN_ROBO , distance 5 priority 15
    link-monitor:
    srcintf PORT1
    server 192.168.4.254
    gateway-ip 192.168.8.254
    source-ip 192.168.8.253
    update-static-route enable (default)

    when the MPLS link it's up you have a routing table with both routes installed but with MPLS path preferred/active, something like the following from cli:
     
    FGT-LAB # get router info routing-table static
    S       192.168.4.0/24 [5/0] via 192.168.8.254, PORT1, [10/0]
                          [5/0] is directly connected, VPN_ROBO, [15/0]  (this is the floating route with less favorable priority 15)
                          
    when the MPLS it's down on any of the two sides, the only route active should be via VPN_ROBO.
    On ROBO fortigate of course you have a simmetric configuration.

    Without the HQ probe you have a blackhole since the HQ originated and obviously ROBO return path  are still routed to MPLS using the till valid route installed in the RIB of HQ fortigate!!
    For statefull established sessions route re-evaluation does not happen until the session expire or a new one is established..
    For antileak blackhole route in case of both link fail there is already a good post here:

    https://forum.fortinet.com/tm.aspx?m=120834#120872
     
    Hope this clarifies the problem better.
    Best Regards,

    Antonio
     
     
    #4
    Jump to:
    © 2017 APG vNext Commercial Version 5.5