CARP failover when GW fails
-
Hi,
currently my setup is as follows. I have two firewalls with carp enabled. The WAN Interface is a physically one. The LAN interface is devided into multiple vlan's. I use on all Interfaces carp for failover. This is working flawless.
So now i have the posibility to split both boxes to two diffrent housings. Between both housings i run a WLAN-bridge with VLAN's enabled. So i can bring the VLAN's for LAN and also for WAN to both housings. We would also have two independent ISP-Uplinks. One with 30M/4M and the second one with 4M/512k (which will be only used when the main uplink fails).
CARP won't be the problem, because of the same VLAN's on both sides.
My problem is the WLAN-bridge. When let's say the mainlink fails, pfsense will be active on main side and won't automatically change. All internet traffic from backup side, went through the WLAN-bridge to main side (LAN default GW - primary pfsense) and went back via the WLAN-bridge to backup WAN-GW, because the main WAN-GW fails.
Is there a possibility to switchover carp if the GW on the main side fails to the backup pfsense on backup side?
There is also a second topic in routing forum, but now i will only check the possibility to enable the automatic failover. ifstated can't help, because i can't bring down the physical interfaces, because then i don't have the possibility to receive carp messages on sync Interface, because sync Interfaces is only a vlan-interface.
Thanks in advance,
regards
Herbert -
Hi,
can two CARP-groups per interface/vlan help?
One carp for backupside with active on backup (carp-ip is the default-gw for backupside), and the second carp for mainside with active on main (carp-ip is the default-gw for mainside).
This should solve the problem with double data traffic on WLAN-bridge, and also the load-balance the firewall,…What do you think?
regards
Herbert -
CARP and multi-WAN are two separate, unrelated things. Though you could hack apinger's config to run a custom script that disables CARP when a WAN goes down and triggers a filter reload, and another one that re-enables it + a filter reload when a WAN comes back up.