Thanks for reply.

In case people still experience this issue (I did very recently), I made a writeup of the solution:

http://sysadminadventures.wordpress.com/2010/03/22/fixing-vm-based-pfsense-carp-announcement-echoes-when-using-teamed-network-adapters/

After doing some more digging, it appears the answer lives here:

http://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Limiter

Still a little confusing since this Pipe doesn't really act like a true interface.

Yes, you're correct on both counts.

That should be state table – I fixed that in HEAD.

And you can leave it blank if you want, it will use multicast to update.

I found the answer. It was caching. After the server was rebooted, NAT didn't work anymore and I had to recreate the Proxy Arp entry in the pfSense.

No, not yet, but I was planning on it:  I dug a little deeper in previous posts and found a similar problem which was fixed by rebooting a router.  After reading your reply, I'm confident that doing so (in conjunction with having the right type of VIPs) will take care of the problems I was having.  I can't try again for a few days because another project got elevated priority.  Thanks very much for your response.

Is your outbound nat set up to use this VIP?

Are you trying to reach more redundancy by using two subnets or you really need to connect two subnets to LAN?

You can explicitly disable multicast/broadcast and put these rules on the top.
Or alternatively - do not allow ANY protocol to ANY address but allow only traffic you really need to allow.
First approach is more efficient as multicast/broadcast packets are droped without going through all rules before being dropped by 'default deny all'.

What does that mean please?
@cpliu903:

when R1 sync to R2, R2 change status to master,  not backup.

ok..thanx..that was my guess too.

I believe some people have gotten this to work by adding 5 vlan interfaces and setting them all for DHCP. I'd do a forum/docs search going down that route and see if you can turn up better results. I seem to recall it coming up within the past two weeks.

I have not given all the details:

I have configured squid to bind on the LAN if.

I have a real IP on the WAN (ip of class 88.xx.xx.12/24)
and several VIP (ips of  class 93.xx.xx.0/24)

I need the squid users to come out with one of the  VIP, by adding
directive tcp_outgoing_address 93.xx.xx.10  in squid conf.

How can I do  to do that?
(I think I need carpdev to have VIP on virtual interface CARP)

kind regards

You could put a dumb off-the-shelf router in NAT mode in front of the pfSense.
Or if the modem supports that, reconfigure the modem.

Basically put a static, private subnet in front of the pfSense.

@GruensFroeschli:

Are the additional IPs routed to your WAN?

They are routed to my PPPoE address.  They are not configured on an adapter other than as virtual IP's.

@GruensFroeschli:

Are they all in use right now?

The 8 IP Block is fully utilised via 1:1 NAT and are all working fine
The 16 IP block is utilising 2 IP's at present.  1 is NAT, the other is configured as the live IP on the virtual linux system

@GruensFroeschli:

Do you have the public IP directly on the server?

The only live IP configured is the PTP ip for my ADSL connection

@GruensFroeschli:

There are several ways to go at such a problem.

Bridging VIPs –> The public IP on the pfSense, the internal servers have private IPs, traffic from the public IP forwarded to the private IP. routing
You cannot use VIPs if you have the public IP directly on the server itself.

Presently, VIP's and routing are accomplishing things for all the other IP's.
The IP that is causing the issue is the virtual machine configured with the real world ip (no internal IP address allocated)