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