Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 1447 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec connections go down very slowly

Anthony Anderson

Is there something other than the gateway monitoring that takes a tunnel down? 

I ask because my device (SFOS 18.5.3 MR-3-Build408) has two tunnels, a primary and a backup, to another XG(SFOS 18.0.5 MR-5-Build586).

Connection type: Tunnel Mode

XFRMs: configured as a /30 

Gateway Monitoring: pinging the other end of the tunnel's XFRM(the other /30) 

Heres my health check settings:

Problem is when I pull my WAN1 cable, the WAN link monitoring takes it down and the Gateway monitoring registers the 10.210.153.197 as unpingable on the other side of the tunnel BUT the IPsec connection keeps that tunnels "Connected" state green for nearly 2 minutes and 40 seconds before it finally takes it down. That's way to long to wait for tunnel traffic to resume. 

Does anyone have any ideas for this issue to bring the tunnel down faster? 



This thread was automatically locked due to age.
  • 0 in reply to Wayne Folta

    There is no real relationship between Tunnel and Gateway. Because gateway is something virtual, while the tunnel is a "physical" component. 

    A Gateway can be a Router within your network, it can be your ISP network, it can be everything. It is something you create on the firewall. 

    The Tunnel is the actual "Link" between two peers. It is the object, the firewall is using to get to some place. 

    SD-WAN rules works with the gateway. If the gateway detection notice a dead peer, it will move to the next gateway. This is in no relationship with the underlaying medium. If the Tunnel or the "cable" to the gateway peer is still there, SD-WAN does not care. It will take the connection down. 

    The only downside is, and thats the problem with ICMP: If you have a active connection, the application will notice the Tunnel is actually dead and build up a new connection. The new connection will use the new Link. That is how TCP/UDP will work. But ICMP will still pump ICMP requests through the dead link because the connection is still there. 

    Therefore ICMP is not the best way to test this scenario, as it will indicate this "it takes for ever to switch", which is actually not correct. It will likely be refreshed by the packets and the underlaying tunnel interface will catch it and still send it. 

    But a TCP/UDP application will likely catch up this rather quickly and rebuild the connection. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Ok Im going to test this with VoIP

  • 0 in reply to LuCar Toni

    And Gateways that are associated with Ports are considered to be WAN Links and can be managed by the WAN Link Manager (and also  used in SDWAN). Is that correct?

Unfiltered HTML