Hi ! It's meant as more than 500 ports ;-) Am 25.11.2011 um 14:51 schrieb "Ugo Bellavance" <[email protected]>:
> On 2011-11-23 23:43, Daniel Davis wrote: > >>> >>> We are thinking about running a redundant (CARP) setup with one pfSense >>> on our VMWare cluster, and one on a physical, separate machine. >> >> I would not recommend a hybrid physical/virtual CARP cluster as CARP is >> entirely network reliant. In a physical CARP cluster best practice is to >> dedicate a network interface on each machine for CARP with a crossover cable >> between them so that even in the event of a switch failure they can still >> talk and elect a master. You would need a dedicated NIC per host, an >> additional physical switch and additional vswitches to achieve the same sort >> of resiliency in a mixed physical/virtual configuration. This can get >> expensive and adds additional points of failure, but without it you run the >> risk of ending up with two masters (i.e. split brain) if the connectivity >> between your physical and virtual networks were to fail. vmWare HA is your >> friend here, it will remove the possibility of a split brain fo >> r you if both hosts are running in the cluster. HA is not network reliant >> (as long as you are using a separate storage network), it uses a combination >> of network and shared data store heartb >> eats to monitor hosts and VMs. One host can lose network connectivity, CARP >> will failover the firewalls, the cluster will detect a host isolation >> response and restart the failed VM on another host, all very orderly and >> controlled with less than a couple of seconds of downtime and no physical >> intervention. >> >> We use two firewalls with CARP in a vSphere cluster, works very nicely. >> >> The things to remember if you go with the two virtual machines are: >> >> 1. Make sure you follow the instructions for CARP and ESX/ESXi from the >> wiki. >> 2. Change the host that ESXi pings to determine its network availability. >> If you leave this as the default gateway, the ESX host that is hosting the >> master node will never fail over even in the event of a network outage, as >> it will still be able to ping the VM. This must be something that is highly >> available, we use the address of the stacked switches in our blade chassis. >> See >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002478 >> >> If you can tolerate a minute or two of downtime in the event of a host >> failure you could even consider a single pfSense VM and just trust vmWare HA >> to do the failover. > > I'm pretty sure that we could live with a few minutes of downtime, so that > would save the carp setup. However, I would reserve the 2 other IP addresses > in all my subnets in case. > >> >>> >>> Concerns: >>> >>> 1- NAT Reflexion - We don't have a split-DNS setup. CheckPoint does >>> seem to manage NAT Reflexion perfectly. >>> >>> 2- Ease to migrate the configuration to pfSense - I would set a pfSense >>> VM in parallel and start migrating all the rules manually, but I'm >>> scared about missing some or seeing a situation where the Firewall-1 >>> can >>> do it and not pfSense. >>> >>> 3- Backups. Are automated backups (of the config, at least) possible >>> even w/o a service contract? >>> >>> Can people share their experience with this kind of scenario? >>> >>> Don't hesitate if you need more info. >>> >>> Thanks, >>> >>> Ugo >> >> >> pfSense works well for the most part, the Snort package has had a few issues >> in the past but once it is working it works well, NAT reflection works fine >> and see the wiki for automated backups >> (http://doc.pfsense.org/index.php/Remote_Config_Backup). The VPN options are >> excellent so I don't think you'll have any issues there. IPv6 is still not >> supported but this was not an issue in our case. >> > > Great thanks. I thought there was problems for NAT reflection for port above > 500, but is it port range over 500 ports instead? I wouldn't need that. All > my internet-facing servers expose 1 to a few ports. > >> As you will find out, the free support provided on the mailing list is often >> better than the help you get from most CCSP's. > > :) > > Thanks, > > Ugo > > _______________________________________________ > List mailing list > [email protected] > http://lists.pfsense.org/mailman/listinfo/list > _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
