CARP alternative
-
CARP sends the same type of traffic that VRRP does, only a slightly different format.
As far as I can tell from the man page of CARP and the VRRP RFC, there is a difference in the traffic.
VRRP promotes a single virtual MAC address, whereas CARP makes use of a multicast MAC address.The OpenBSD man page (http://man.openbsd.org/OpenBSD-current/man4/carp.4) says:
However, there are a few OS and routers that do not accept a multicast MAC address being mapped to a unicast IP.
Which I believe could cause some trouble, though I am neither a network nor a virtualization expert.
The manual also describes some work arounds (i.e. ip-stealth mode), which I think are not a good idea to
use in a network managed by someone else.Anyhow, you are propably right about saying that using CARP should be possible, too…
Cheers!
-
Just for the record, my provider confirmed that the Multicast MAC is the problem.
Their cloud network infrastructure doesn't support it yet.
Perhaps they are using Infiband which makes trouble or so, I don't know. :o -
@jimp said in CARP alternative:
There are no alternatives to failover, CARP is the only working mechanism at the moment.
We're looking at freevrrpd but if the provider doesn't support CARP, that's unlikely to work either as the base mechanism is similar.
Almost five years later, I'm wondering if freevrrpd is still not an option for pfSense @jimp?
Unlike CARP, VRRP relies on broadcast with one single vMAC instead of multicast MAC addresses. The big advantage of VRRP is, that it does NOT require promiscuous mode on virtual environments like VMWare vSphere to be enabled, which otherwise imposes a security-risk in any business-critical environment.
Although it's currently unmaintained, there even is a port for freevrrpd available already: https://www.freshports.org/net/freevrrpd
Thanks
-
No, we have not attempted to utilize that.
-
Since CARP does not work on cloud virtual environments (AWS, Google, Oracle cloud, etc), is there any other way to make pfSense work in HA configuration for cloud environments?
If not, is there any plan to make HA cloud configuration to work in the near future? -
Hi. Is there any update on this matter please? Meaning, CARP support or alternative for pfsense usage on Public Clouds (AWS, GCP, Azure etc) ?
-
@ErsanY Thanks for making this post active again. CARP is very limiting with deployments due to the IP addressing requirement.
-
@ErsanY said in CARP alternative:
Hi. Is there any update on this matter please? Meaning, CARP support or alternative for pfsense usage on Public Clouds (AWS, GCP, Azure etc) ?
https://docs.netgate.com/pfsense/en/latest/solutions/aws-vpn-appliance/ha.html
-
@jimp What about on prem? Is CARP alternative still being investigated?
-
The only possible alternative would be VRRP which has the same limitations as CARP, which is already covered higher in the thread.
-
I've been using pfSense in HA using UCARP in Oracle Cloud.
Oracle Cloud has L2 VLAN that allows broadcast (but not multicast) messages. Therefore, CARP doesn't work, but UCARP works well because it can be configured to use broadcast messages instead of multicast.
It would be great if pfSense incorporated UCARP as an alternative for HA so that it could be used in cloud installations.
Do you think this is possible? -
pfSense Plus has unicast CARP already.
-
@jimp said in CARP alternative:
The only possible alternative would be VRRP which has the same limitations as CARP, which is already covered higher in the thread.
Well not having a mandatory /29 would be helpful which would be the main and important differentiator hence vrrp is desired
-
@michmoor I realize I’m coming in at the end of a 9 year old thread, but technically a /29 isn’t required for WAN. It can be done with private IPs in the right situation, e.g. Comcast business Internet provides both NAT (10.1.10.x) and passthrough/static routing at the same time. Or the docs mention leaving router2 not able to connect out without failover, using one IP, though that’s not ideal.
-
@SteveITS said in CARP alternative:
technically a /29 isn’t required for WAN.
For High Availability, i believe it is. CARP isn't ideal.
-
You can use a single address for CARP on any interface, but it's primarily practical on LANs. If you do that on all of the WANs, the secondary will have no upstream connectivity so it can't operate effectively. If the upstream router allows public and private addresses some of those limitations might be alleviated but it's something you'd have to try on a case-by-case basis.
It's covered in the docs:
https://docs.netgate.com/pfsense/en/latest/highavailability/index.html#ip-address-requirements-for-carp (second paragraph in that section)
-
@michmoor We have a client using private IPs as I described. Both routers can update. They actually had a small block but at the time needed multiple IPs for various services so they were all shared. (Now just one)
-
@SteveITS Yeah you can use a RFC1918 layer but its just not as clean as putting routable addresses on the WAN. Double-NAT
The concern i have with this type of design is port forwarding and/or hosting services. Not ideal but can work.
@jimp if the secondary firewall needs to install patches/packages, is that when you just flip it to Master (One WAN IP being shared).
Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
@michmoor maybe but since the shared “CARP” public IP is used on WAN there’s no practical difference in my mind.
Edit: yes if using only one IP it’d have to be master to update pfSense. Or pfB lists etc.
-
@michmoor said in CARP alternative:
if the secondary firewall needs to install patches/packages, is that when you just flip it to Master (One WAN IP being shared).
It needs to have packages and updates at all times, not just when it's master. Otherwise you'd have to fail over to it to do any sort of maintenance, which defeats the idea of HA to reduce disruptions.
