Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    I am suspicious that the interaction of FRR and IPSEC both using CARP is resulting in very slow IPSEC release during failover

    Scheduled Pinned Locked Moved FRR
    1 Posts 1 Posters 209 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • nzkiwi68N
      nzkiwi68
      last edited by

      I still got this issue, now I can replicate it easily at 2 completely sites, all 2.4.4_p3 and both using;

      • FRR and OSPF (0.6.2)

      • HA pair

      • IPSEC VTI tunnels bound to a CARP IP address

      • FRR set to follow the lan CARP address (so FRR off on the backup firewall)

      Here's a continuous ping across the VPN from site A to site B.

      Reply from 10.10.40.1: bytes=32 time=4ms TTL=253
      Reply from 10.10.40.1: bytes=32 time=7ms TTL=253
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Reply from 10.10.40.1: bytes=32 time=4ms TTL=253
      Reply from 10.10.40.1: bytes=32 time=3ms TTL=253
      Reply from 10.10.40.1: bytes=32 time=4ms TTL=253
      Reply from 10.10.40.1: bytes=32 time=3ms TTL=253

      First timed out, that's the primary firewall being rebooted, 4 pings lost and the backup completely takes over. Very acceptable. Excellent.

      Now the slow bit... The primary comes up, CARP takes over and takes ages for things to settle and go online.

      Reply from 10.10.40.1: bytes=32 time=3ms TTL=253
      Reply from 10.10.40.1: bytes=32 time=17ms TTL=253
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.
      Reply from 10.10.40.1: bytes=32 time=3ms TTL=253
      Reply from 10.10.40.1: bytes=32 time=4ms TTL=253

      After digging, I think the cause is the VPN, IPSEC, it's just not getting released from the backup firewall in a timely manner, it seems to hold on and on and on and keeps running IPSEC VPN tunnels. I can speed up the fail back by logging onto the backup firewall and in IPSEC status stopping the IPSEC tunnels.

      I wonder if the issue is because my IPSEC tunnels are using a CARP IP address and /or some interaction with FRR?

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.