Single IP + Failover + 2.0 RC1 ?
-
I've been happily running 1.2.3 for a year now, and now want to do the following:
- Upgrade my machine to 2.0RC1
- Add a 2.0RC1 VM to my ESXI machine
- Configure both so that, if one fails, the other still works
- I only have one WAN IP Address (Cable Modem)
Can this be done? In the 1.2.3 book I have, it said something to the effect that you need two WAN IP addresses in 1.2.3, but in 2.0, you may only need one IP. I've searched for an hour, and I still don't know how or if this is possible. Can anyone help?
-
You have to have at least 2 public IPs, one for each, and to have stateful failover you must have 3 static public IPs.
-
I was my understanding that we where going to be able to have 1 IP address and multiple se\\rvers. Has that fuction been dropped;
Rc -
I was my understanding that we where going to be able to have 1 IP address and multiple se\\rvers. Has that fuction been dropped;
It never existed, FreeBSD doesn't have carpdev. We're hoping to port that ourselves at some point, but no ETA.
-
i anxiously followed that carpdev porting idea a while back. I used to have multiple IPs from my provider and a sweet pfsense failover setup, but not anymore.
What I've done as a poor mans substitute is to configure my DSL modem(ancient westell 6100) nat feature to "static nat" traffic to a single 192.168.x.y ip. I then use that ip as the carp/vip IP and then assign 192.168.x.y+1 and 192.168.y+2 to the wan ports on the A and B pfsense machine respectively. the westell still seems to allow other 192.168.x.z ips to talk and not hit the static nat rule, which allows both pfsense boxes to talk to the internet doing normal NAT, and anything unknown coming in, it sends to the CARP ip.
with the carp ip active on a machine it should be used as the src ip, so that traffic will come back to the same machine or in the event of a failover, the other pfsense box will take over the carp ip and get the traffic.
i was worried that the mac/ip changing at failover would confuse the modem but it seems to handle it in my testing.
in the end it has worked out fairly well for my purposes although i dont do any of the problematic type applications like video conferenceing, voip etc and i have no incoming services other than openvpn tunnels.
the openvpn tunnels are just setup on the dsl modem as specific nat rules that map different UDP ports to each firewall.
the openvpn client has two remote ip entries, oen with each port and it will rotate through them if one goes down… but that means it goes down and reconnects. but i'm just doing simple road-warrior type vpn tunnels so it's not a problem.anyway, i've been happy with it.