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

    Accessing CARP Backup Device over IPsec

    Scheduled Pinned Locked Moved IPsec
    2 Posts 2 Posters 902 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.
    • J
      Jason Crowley
      last edited by

      We are having trouble passing traffic from clients on one side of an IPsec tunnel to a backup firewall on the other side.  Traffic initiated at the backup firewall also will not traverse the IPsec tunnel.  We have a two-site configuration where each site has a primary and backup firewall in a CARP HA configuration.  The sites are connected with an IPsec tunnel.

      We have found that it is impossible to access the backup firewalls across the IPsec tunnels because each backup firewall maintains SPDs for traffic directed to the other site even when the appropriate IPsec tunnel is not up.  The SPDs grab the traffic before it hits the normal routing table and force it into a black hole since there is no active IPsec tunnel to service the traffic.

      If I manually delete the SPDs on the backup firewall, traffic will pass from the backup firewall through the IPsec tunnel on the primary firewall to the other side of the tunnel; however, when we fail over to the backup firewall, the IPsec tunnel does not come up.

      Has anyone else had experience with this?  Is there a known workaround?

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        It's a known/expected issue.

        You're probably already on manual outbound NAT. Add a rule there to NAT out LAN from the remote IPsec subnet source to a destination of the secondary's LAN IP address, translated to 'interface address'. Add another with a destination of the primary's LAN IP address (or use an alias and one rule).

        That way when you try to reach the secondary it appears to originate from the primary and vice versa, avoiding the VPN knowledge issue on the secondary.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

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