Thank you jimp it work :)

Ah, I think I have a better understanding of what is really happening here.

The only IP addresses that are showing up are ones that are for a Microsoft Load Balanced IP with two members.  I guessing what is getting blocked are the packets that are viewed as out of order by the non-active based on the fact that the primary firewall has already gotten past the part of the connection setup that a given packet type would be expected.

So sorry for the false-alarm.  I just noticed when I went back through the logs that it was only happening on the LB IPs.

The more I'm exposed to this implementation of load balancing the less I like it–unfortunately, we are committed to this at least for the near future.

Thx Jimp for your reply. Your method solve my problem. Cheers!  :D

In that case you'd use the whole /27 on a "DMZ" segment (And you can still do CARP there if you want if you need redundant routers) which doesn't get NAT, and then have a "LAN" segment with private IPs that does get NAT. You can filter between the interfaces that way.

If you want to split the /27 on the inside into multiple interfaces you'd have to setup one interface with the /27 on it and then bridge the second internal interface to that one. I try to avoid bridging if at all possible, though.

Hi Jim, Thanks for the clarification. Makes perfect sense.

Melvin

If anyone cares, we setup OSPF and removed the GW's

Ordered.. thanks

To add more to the description currently:

1. There isa VIP (Carp/LAN) setup 10.0.0.3
2. Load balancer is configured on LAN 10.0.0.3
3. Everything IS WORKING from my workstation that's vpn'ed in. IE. I can connect to the LB system at 10.0.0.3 from my vpn'ed machine

Now I just have to be able to connect to the LB IP from a machine located at say 10.0.0.4.

Interesting. I was thinking of the same thing. But i was just gonna let The Master PFsense connect to one switch with one cable, and the Slave Pfsense connect to the other switch.

Isn't carp set up such that if the connectivity of the LAN interface fails(i.ex switch failure), it will make the pfsense-slave take over? The you would just fix the switch, add it back to stack, and promote the original master again? That's how I thought i worked. But I'm asking more than telling you. I haven't bought my equipment for this project yet and ProCurve switches AND pfsense is totally new to me. hehe

Please let me know how this turns out for you. I'm interesting in hearing your experiences since this sounds similar to what i'm trying to do.

You can't sync proxy ARP VIPs between CARP nodes, it would cause an IP conflict.

If the IPs are in the same subnet as WAN, use CARP VIPs. If they are in a different subnet, have your ISP route the other subnet to your WAN CARP VIP and use the 'other' VIP type.

On 2.0 you could also add an IP alias inside the second subnet on both boxes and then setup CARP VIPs for the remaining IPs.

Yep, that's correct.

I have resolved this issue. It appears the comcast modem just needed to be rebooted.

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~~