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

    Firewall high availability virtualization or carp?

    Virtualization
    5
    7
    4.5k
    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.
    • E
      eldblz
      last edited by

      Not sure this is a the right place for this question, if not my apologies

      My company is on the verge of a major network improvement, we will expand our network to remote offices via radio bridges.
      The firewall will be handling:

      • 3 mission critical networks,
      • 3 non mission critical networks
      • 3 mission critical voip trunks
      • 4 wan links
        The firewall solution will be Pfsense.

      To achieve high availability I can't decide if it's better to use pfsense carp or virtualization (using hypervisor HA multiple host, live migration etc). Which solution will you use and why?
      Does one solution has some limitation over the other (for istance I heard carp has some limitation with traffic queues)?
      In case of virtualization which hypervisor will you choose?

      Consider we have pressing budget constraints so the solution must minimize the costs.

      Thank you in advance for your kind replies.

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        I wouldn't implement such a complex setup on an VM.

        Over all I think CARP has some advantages:

        • the firewalls monitors the CARP IPs an can take over immediately

        • states are synchronized between the firewalls, so connections ride out a failover

        • firewall setting you make are synchronized to the backup instantly

        • and certainly it is more hardware efficient

        I don't know about limitations of CARP. Maybe the traffic queue issue affects WAN loadbalancing. You have 4 WANs, are they intended for loadbalancing?

        A disadvantage of driving pfSense directly at the hardware is that you have to care for compatibility.
        I recently have installed pfSense on 2 DELL R210 II each with a 4 port Intel NIC card for CARP redundancy. I had to make some drive adaption to get it work smoothly.

        I had installed some pfSense on KVM VMs with no more than 5 NICs for testing, also I built a CARP cluster with it. However this is an other environment as you need for production use. In your case must have a plenty of real NICs on hardware and have to hand over this to the VM. I haven't make such researches yet.

        1 Reply Last reply Reply Quote 0
        • E
          eldblz
          last edited by

          viragomann thanks for your reply.

          Actually I have plenty of experience with virtualization but none with CARP I'll definitely run some lab before put it in production.

          Probably due budget constraints we'll not be able to afford server class hardware I was thinking about custom built PC, doing some math (considering some network will be handled via VLAN) I'll need about 8 NIC per firewall.

          1 Reply Last reply Reply Quote 0
          • K
            keychain
            last edited by

            Hi,

            I'd prefer CARP, because your networks (or at least 3 of them) are mission critical. All HA-solutions I've seen so far need some time to start the VM in case one Host breaks down, and this usually means some seconds. Just make sure the 2 VMs won't ever be hosted by the same node and you're good to go. Perhaps think about a direct, hardwired connection for CARP, so you don't interfere with the normale network traffic.
            But, to be honest - if it's mission critical and one of the most sensitiv points in your network setup, that's where I definitely would invest some money to get at least a decent physical Server. Perhaps something like the supermicro twinseries - two servers, one Box, no hassle.

            Best regards,
            Keychain

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

              Hypervisor-level HA is a good option for things that don't have other means of providing HA. For things where you have other options, those other options are usually better. Hypervisor-level HA only protects you from hardware failure induced outages (and potentially other outages in related things, storage, etc.). It gives you no HA for scenarios like needing to upgrade a system. For that reason alone, HA at the firewall level is best.

              Sure, add in HA at the hypervisor level for additional protection, but it shouldn't be your first line of defense for your firewalls. Or for that matter anything else you can cluster in a means that you can update the systems without causing a disruption.

              @keychain:

              All HA-solutions I've seen so far need some time to start the VM in case one Host breaks down, and this usually means some seconds.

              VMware at least has an option to run a VM on two pieces of hardware simultaneously and have it seamlessly switch over more or less instantaneously. The downside being it's consuming those hardware resources all the time on two physical boxes. Even with that, I'd still strongly recommend firewall-level HA (CARP+pfsync+config sync) over VM-level HA, or in combination with it.

              1 Reply Last reply Reply Quote 0
              • D
                deagle
                last edited by

                Another downside to VMware FT is you can only use one vCPU. Also keep in mind FT is not application aware and can't failover if something goes wrong inside the guest OS.

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

                  @deagle:

                  Another downside to VMware FT is you can only use one vCPU. Also keep in mind FT is not application aware and can't failover if something goes wrong inside the guest OS.

                  That's another good point. Our HA will handle that, as well as other potential problems that FT may or may not detect. Like if there is a network connectivity issue on a single NIC or VLAN of the primary VM firewall, the secondary will take over. FT, and any other similar hypervisor-level HA, may have no means of detecting such issues.

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