CARP alternative
-
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.
