Secondary firewall in CARP setup attempting IPsec negotiation

  • I have a pretty standard CARP setup for the connection from our office to our colo. The colo side is not set up for CARP.

                 |-- LAN -- office-fw1 -- WAN --|
                 |                              |
    office LAN --+                              +-- Internet -- WAN -- colo-fw -- LAN
                 |                              |
                 |-- LAN -- office-fw2 -- WAN --|

    office-fw1: pfSense 2.0-RELEASE
    office-fw2: pfSense 2.0-RELEASE
    colo-fw: pfSense 1.2-RC2 (yes, I know it's old)

    office-fw1 is the primary and office-fw2 is the backup. They have fully synced configs using pfsync There is an IPsec tunnel from office-fw1 to colo-fw (using the CARP interface) that is working fine. However, office-fw2 is also trying to establish the same IPsec tunnel (same exact settings as office-fw1). This connection is ultimately failing because the colo-fw is trying to establish a return connection to the CARP IP address in the office, which is assigned to office-fw1. It attempts this roughly every five minutes, producing IPsec log entries in both office-fw2 and colo-fw regarding the failures (failed due to time up).

    My question is actually concerning the backup firewall attempting this connection. Is it normal for the backup firewall to attempted an IPsec tunnel connection on a CARP interface when that CARP interface is currently in the BACKUP state? In a perfect world, I'd imagine it wouldn't try to establish any connections over the CARP interface unless it is considered the MASTER (since that should be the only way it would work). I was hoping there would be some way to avoid the "bogus" log entries that are generated, especially since the remote end is running 1.2, which doesn't provide as much information as 2.0 in regards to identify which tunnel is causing the failure.


  • Rebel Alliance Developer Netgate

    It is normal for it to try, yes, but if it's bound to the CARP interface the traffic won't normally ever make it out of the box, so it does nothing but fill the logs on the secondary with attempted connections.