CARP and WAN
-
That is correct.
-
Or, if you attached a router to each ISP's connections, you could connect the routers to both (or all) your systems. Am I right?
-
tacfit: I don't quite understand what you're asking, can you re-state that?
-
Yeah, I didn't get that either ???
-
A picture's worth a thousand words. See the horribly crude attached one.
Both routers make the connection to their respective ISP. Each ISP only needs 1 static IP. The routers are then attached to the WAN interfaces of your pfSense boxes.
Right about now, I'm realizing the fatal flaw in my plan… I suppose if you used a DNS round robin (as we do) you could mitigate some of the risk of one connection being down, but you're dependant on the DNS servers magically helping out...
:-\
 -
that diagram should work, you'll need 3 static IP's per ISP minimum.
pfsense has a DNS server package that handles failover so DNS shouldn't be an issue.
-
I must be missing something. I only see the need for 1 IP per ISP.
-
Search for carpdev. It has not been ported to FreeBSD as of yet. It is on my list but that seems to be expanding quite quickly these days.
-
Hmm, carpdev looks interesting. Would certainly make it easier to implement CARP on a small subnet.
RE:
@tacfit:I must be missing something. I only see the need for 1 IP per ISP.
The current system requires you to have at least three IPs for the WAN to have CARP. One for each interface, and one or more CARP virtual IPs. Let's say you have the 1.2.3.0/29 subnet for your WAN, and the provider's router is at 1.2.3.6. Firewall one would have the WAN addressed 1.2.3.1 gateway 1.2.3.6 Firewall two would have the WAN set to 1.2.3.2 gateway 1.2.3.6 Then you could create CARP VIPs for 1.2.3.3, 1.2.3.4, and 1.2.3.5 Any port-forwards, etc. to the CARP IPs would be reachable even if one of the firewalls was down. Your DNS would point to 1.2.3.4 and you wouldn't have to round-robin the DNS.
If you are not using CARP on the WAN, then there is no reason to cross-connect the connections from the routers. But then the incoming connections will not be fault tolerant. Multiple A records in not a great solution, as half the queries will fail if either of your lines is down. You can pull the bad record as soon as the line is down, and have a low TTL, but it won't be as painless as CARP. -
Yeah, I got ya.
