any help or comment?

Thanks,
Hans

so I have to set wan /16 and vip /16 ?

Seems to be bad luck in that case. You'll have to wait for the next major version (most likely 2.0) which has support for another type of alias that should be able to handle this condition.

okay this is what i found if you have a address of *x.x.x.25 and you also have a address of x.x.x.2 you will ned up  with the same carp numbers. I have fixed it but still does not solve my problem of not being able to download files or email attachments. I have tried every suggestions mentioned on the forum. So i am open to new ideas

http://faq.pfsense.com/index.php?action=artikel&cat=1&id=167&artlang=en&highlight=bad%20gateway

We enable preepmtion by default now, that's why the box is missing (the tutorial was not updated regarding this). I'll have a lokk at the doc if it can be made more clear or more easy to understand.

Oops, thats wrong :)  I'll get it updated.  Thanks

See http://www.countersiege.com/doc/pfsync-carp/ for how it works.

Thanks for the quick response.  Flipped everything over to Proxy-ARP and it works.

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.