Here's how I solved this problem for our office (migrating a legacy 4.9 firewall with ipfw to pfSense).

The first thing I noticed is the lack of support for alias IPs (in the traditional definition of the concept, i.e. "ifconfig xxx0 1.2.3.4/27 alias").

So I went around the forums, and didn't find a good solution that wouldn't confuse CARP or require sticking a custom startup script in /usr/local/etc/rc.d/

One solution I did come up with, and that I have used before with success in NAT-before-tunnel IPSEC encapsulations, is as follows:

create Virtual IP of type "proxy arp" on the inside interface (Firewall -> Virtual IPs), for example "172.31.31.1/32" (what we use) create a an advanced outbound NAT rule of the type: nat on EXT_IF inet from 172.31.31.0/24 to any -> (EXT_IF) round-robin the tricky bit: route add 172.31.31.0/24 -iface INT_IF

Now the last part is tricky because the forms don't support -iface sis0 (the inside IF).  Looking in the CVS code:

http://cvstrac.pfsense.com/chngview?cn=10696
http://cvstrac.pfsense.com/rlog?f=pfSense/usr/local/www/system_routes.php

… this was introduced, then rolled back:

http://cvstrac.pfsense.com/chngview?cn=10869

Scott's explanation:

"Remove interface gateway option. It doesnt do what I wanted, and the same can be achieved by plugging in the next hop gateway."

Well, it would have done what I wanted :)  Additionally, I am missing an example for the scenario described in the above commit message -- I am doubting about the correct way to go about doing this kind of forwarding with PF, through the pfSense interface...

So in the meantime I have an rc.d script doing "route add 172.31.31.0/24 -iface sis0" and everybody's happy.  Hope the input helps, and hope real IP aliases will be introduced sometime in the future.

Phil

first you have to talk to the develpers of pf ( pf is the firewall of freebsd that pfsense uses)
if they made that option in pf then the pfsense core team can make a option for pfsense to use it

so unless pf adds those options there is no reasen for a bounty

NAT 1:1 to FTP servers from one VIP to ServerPool 192.168.2.2 and 192.168.2.3?
I though NAT 1:1 is one VIP-> one server.

Hans

Not sure there was anything wrong with the package except it wasn't complete.  ifstated is  a pain to configure well although somewhere I think I have some code partially written using the latest OpenBSD code that I ported over.  I might be willing to resurrect it, depending on how much it's worth to you..I'm trying to scrape together some cash for a new laptop right now.  I think I have a fairly decent idea of what it is you're trying to accomplish, but I think a network diagram would help fill in a couple of the blanks for me.

–Bill

i found that just adding a shell script call ifcfg.sh to /usr/local/etc/rc.d and setting chmod +x on it worked just fine to keep up the alias across reboots.
my script looked as such

#!/bin/sh
ifconfig vr0 alias 192.168.1.20 netmask 255.255.255.255
ifconfig vr0 alias 192.168.1.21 netmask 255.255.255.255

hope this helps you, it worked for me.

Proxyarp is not used for failover.  CARP is.

@hpommer:

Greetings

I'm new to OpenBSD & pfSense and I'm currently looking into a pfSense cluster setup exactly as described in Fig.2 http://forum.pfsense.org/index.php/topic,1014.0.html.
In order to avoid having the switch as single point of failure I would like to connect each pfSense to a separate switch (which is interconnected with its own trunking feature).

I have come across the trunk(4) feature in OpenBSD which means I can setup two NICs as a virtual NIC and let them act as an active/standby pair (I guess the failure criteria is the media link up/down).

My question is would the CARP feature work on top of such a virtual NIC (setup IP, MAC….)?

Thanks for any hints,
hp

FWIW, we don't run on OpenBSD.  So, no this feature won't work and I dunno if it'd work as you describe in Open.

–Bill

I have done all that you mention.  I am using a dedicated interface for carp.  Both carp interfaces are connected via the same vlan and xmlrpc updates are successful.  I have not had the chance to swap out the nic for a pci-x nic yet, but I will start with a fresh install when I do. I will have to wait until the next maintenance window

@sullrich:

http://www.gliffy.com/publish/1040812/L

what make and model of dsl router are you using, will you divulge the ip scheme of the WAN side of the cluster?(dsl router internal and external, WAN-VIP, and wan interfaces on pfsense boxes.)

If you accidentally DO reuse VHIDS, chances are your box is going to core every boot.  To manually fix this without reinstalling:

1.  Disable all NIC's
2.  Reboot into a shell, manually edit /cf/conf/config.xml and remove the corresponding VIP that has a duplicate VHID.
3.  rm /tmp/config.cache
4.  Reboot with NIC's enabled.

Yes, I have DSL and it works fine.  It will require atleast 3 public Ip addresses for one carp cluster.

However this has all been spoken about in even more detail scattered throughout the forum.

No, each CARP IP is one IP, no matter what subnetmask it has. The subnet just has to match the subnet of the interface physical interface the CARP IP is running on. However you can use 1:1 NAT with subnetranges to map several vips to several internal IPs after you have created your VIPs

Each WAN needs to be a seperate Interface or the Natting won't work correctly. Also you would not be able to use policybasedrouting for sites that don't work with loadbalancing for example. If you have a vlan capable switch you can make this work with one physical interface and several vlan interfaces.

Atleast for 1.0, yes.

No, CARP IP and real interface IPs have to be within the same subnet. You could set up your WAN subnet to /29 and use 2 IPs that are out of your range for the real WAN IPs. This way you lose access to a few IPs at the internet but as this most probably are other customers of your provider that might not even run any  public services this should be no problem. Just make sure the gateway IP and the CARP WAN IP is what your provider told you for the IP you have.

@Numbski:

I get it now.  Sorry about that.  I suppose documented this in the wiki would be helpful to others. :\

Yes, please do.

Another update.  Hacom has pulled their boxes from their website.  They've confirmed a serious issue with the PCI bus and are working to resolve the problem.  They've since refunded me for my systems.  Hope they get it resolved soon!

:o

Make sure there is no rules mismatch between the 2 systems. Also clicking the small icon in front of the syslog line will tell you which rule caused the block.

Not in 1.0.

Yes i try, it's OK

Thanks