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

    [SOLVED] Strange: CARP IPSEC tunnel; can ping far side fw1, but NOT fw2??

    Firewalling
    3
    4
    801
    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.
    • H
      HaburGate
      last edited by

      Having a strange issue, been working at it for a while but no luck.

      Configuration:

      2x pfSense 2.1.5 boxes on either end of an IPSec tunnel. Both ends are in an HA+CARP configuration.
      Main site:        172.16.1.0/24
      LAN Virtual IP:  172.16.1.2
      LAN fw1 IP:      172.16.1.3
      LAN fw2 IP:      172.16.1.4

      Branch site:  172.16.5.0/24
      LAN Virtual IP:  172.16.5.1
      LAN fw1 IP:      172.16.5.2
      LAN fw2 IP:      172.16.5.3

      Everything working great (traffic passing through tunnel, routing working as expected, etc).

      BUT, from Main site, I can successfully ping branch fw1 (172.16.5.1 or 172.16.5.2) but cannot ping or reach in any way fw2 (172.16.5.3). However, when I power cycle branch fw1 and fw2 takes over, suddenly I can reach it by both IP addresses (.5.1 and .5.3). Then when fw1 takes back over, branch fw2 becomes unreachable at .5.3 again.

      There is nothing in the firewall logs. I'm guessing it's something to do with firewall rules regarding permitted subnets but due to CARP the firewalls have identical configs.

      PGP Key: 0x82A211A2
      Server:    pool.sks-keyservers.net

      1 Reply Last reply Reply Quote 0
      • dotdashD
        dotdash
        last edited by

        This is a known issue, there was something in the wiki (or somewhere), but I can't find it right now.
        You can only hit the firewall which is holding up the tunnel via the tunnel, the backup one won't have the route active.
        You might be able to fix it by adding a route on the lan via the lan carp to the remote subnet, but I just connect to the public ip when I need to configure the backup.

        1 Reply Last reply Reply Quote 0
        • H
          HaburGate
          last edited by

          @dotdash:

          This is a known issue, there was something in the wiki (or somewhere), but I can't find it right now.
          You can only hit the firewall which is holding up the tunnel via the tunnel, the backup one won't have the route active.
          You might be able to fix it by adding a route on the lan via the lan carp to the remote subnet, but I just connect to the public ip when I need to configure the backup.

          OK, good to know, I spent hours going through all the config options trying to figure out what I was doing wrong, so that's a relief :).
          Thanks for taking time to post the info.

          PGP Key: 0x82A211A2
          Server:    pool.sks-keyservers.net

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            You just need source NAT to manage cross-subnet (whether VPN or otherwise) to work around the lack of routing when in backup status. You don't want to modify routing to try to work around it, you will break something when it fails over. There are examples of that kind of outbound NAT in the book.

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