Ok that clarifies things. Thanks for the quick reply

No, it wouldn't have much to do with a sync failure.

CARP heartbeats happen on the interfaces where the VIPs reside, i.e. a CARP VIP on WAN sends its heartbeats on WAN.
XMLRPC sync happens over the sync interface, it only handles configuration.
pfsync only happens over the sync interface, it only synchronizes states (insertions, deletions, etc)

So a problem with CARP on WAN is nearly always a problem with the switch or connectivity on WAN.

Virtual-IPs term can be deceiving. Its not like your virtual IPs. Virtual IPs under pfsense are public/real world IPs that you can bind on your WAN interface ~~.

Ofcourse if you are using internal virtual IPs then you can bind them as well. But to clear the confusion, think of virtual IPs as real world IPs in your scenario.  :D~~

One word "Bridge"  ;D

32 means just 1 IP. 24 means the whole subnet. Try breaking apart your subnet and use individual definitions.

I have 12 public IPs as virtual IPs using pARP and they have been working since 4 months without any issue at all. pARAP is pretty neat if you ask me.

Click "firewall" then click virtual IPs. Add your second IP there. Dont forget to add rules under NAT if you want to do forwards and stuff.

1. Bitmask settings is very important. Make sure you have the correct bit defined.
2. Try using a different INTERNET connection to access ( aka outside access not access through LAN )
3. True you have portforward ( inbound rules ) defined but did you also define the outbound rules under NAT??

Please confirm and get back to this thread.

Great. Thanks for clearing this up for me.

-Sean

That isn't a gateway in the traditional sense.

What you want is manual outbound NAT. Firewall > NAT, Outbound tab. Switch to manual, and then edit rule for LAN2, and choose the .20 IP for the translation address.

For most packages that will work fine. The package settings do not sync in most cases, so for those it will act like two isolated systems.

It wouldn't sync the interface config (WAN, LAN, etc) and IPs, so you'd have a lot of manual changes to make.

I have also recently switched to U-Verse and have a 2Wire but a 3600HGV (I think this RG is just like a 3800HGV but no TV and/or phone) for Internet only with a block of 64 public static IPs (61 usable).  I simply hate the U-verse RG no bridging allowed to my current Netopia firewall.  After doing some research I want to build/use a pfsense box in place of my old Netopia - so right now am playing around with pFsense in a VirtualBox environment with two real physical NICs. I too am trying to pass through my public IP addresses across the pfsense box.

I see that this thread identifies a solution:

CARP type virtual IP addresses should report as having distinct MAC addresses.

However I am so new to pFsense I just don't understand either the above "solution" or even how to set up my system with U-verse, although once it is configured I am pretty comfortable with entering my own "Firewll: Rules".

I would be very grateful for any sort of step by step configuration (mini guide or recipe that I can follow) such that I can put pFsense between my 3600HGV and my internal network with both private address space boxes and also the assigned public static IPs.

Thanks in Advance

There is no currently supported/working way to do CARP on WAN with a single IP address. You need at least three: One for each box, and the shared CARP VIP.

This may change in the future if carpdev ever makes its way in. From what I understand that lets the routers have IPs in a separate subnet from the shared IP. But for now, with only a /30 on WAN, something will have to talk to that.

In doing so, however, you lose the high availability that CARP gains you and you're back to a single point of failure.

you need a CARP per each vlan, the behaviour is like HSRP, so read about HSRP and you will understand how CARP is working, it is the same.

Same problem here related with DD-WRT wireless access point behaviour.
The problem disappeared after the AP was rebooted to appear again after it was running again.
So looks like a problem in the remote side, not in the pfsense, just it complains about something strange.