this thread's been hijacked enough, please start new threads. Locking this. OP if you want to follow up to this please PM me and I'll be glad to unlock. The rest of you, you need your own thread where people can help you troubleshoot without making a mess of someone else's thread.

Thanks for a good news! :)

The workaround:

Since trying to find a way to get CARP to startup after Quagga OSPF seemed a bit futile, and obviously FreeBSD has no metrics to use for static routes, I needed another solution.

It finally occurred to me that if CARP just wouldn't steal the IP back, then the solution would be pretty obvious.  Leave the IP with whoever has it at that time.  Turns out this works pretty well:

Added sysctl: net.inet.carp.preempt = 0
Adjust CARP entries (which in my case included turning off synchronization) to have the advertising base/skew set the same.

So, now when my router fails, it's just a matter of a second or two while routing tables update their states to stop trying to send traffic through the failed device.

If you're expecting points (green) 2 & 3 to support VRRP, then no.  There's no VRRP support in pfSense.

If you're expecting them to use CARP to each pretend to be (green) .1, then it should work.  Just note that what's past them in the perimeter-net might affect how they work in terms of actually doing failover.  Data has to make it back in, after all, and this is determined by the routing tables, and whether or not the routes from the perimeter-net know that it can take either path (long as it's up) to get back to your subnet.

I imagine though, by this time you've either tried it, or abandoned it, since it's been more than a month.  I just happened to be searching for something similar to what I'm trying at work to see if anyone has gotten through a hurdle I'm running into, but that's a post for another topic.

Make sure you have the CARP VIP selected as the 'interface' for the VPN and not the actual interface (e.g. 'WAN')

When set that way, pfSense 2.0.2 and later will disable the VPN on the backup node until it becomes a CARP master.

@podilarius:

Thank you for the update.

Sure It does make you wonder: why does it (sometimes) then work when you explicitly permit all IGMP in, if the problem is at layer 2?

I believe that the multicast "join IGMP group" and "leave IGMP group" messages must be interpreted somehow by the CARP peer causing it to properly fall into backup state.  These particular switches seem to 'lock' the particular port(s) out of an IGMP group for 260 seconds (default) following an IGMP group membership LEAVE request.  Very bizarre.  5 minutes later or so they start forwarding the packets again.

Anyways, IGMP snooping isn't really a useful addition to this network so it can stay off. :)

Forgot to mention, pfSense version is 2.0.2-RELEASE.

Marco

That wouldn't work without some manual hacking and even then isn't likely to do what you really want/need.

It might be best set set the modem to do PPPoE and then have it do 1:1/DMZ from the PPPoE WAN IP to a CARP VIP on the shared segment. Much less hacking, plus you get stateful failover. It does add another layer of NAT, but it may be unavoidable in this case.

Well, shucks.  Now I need to read up on IP Aliasing because I know nothing about it.

Is it fair to assume that I can use that trick to add a separate block of IP addresses to my firewall as described in the first post?

If so, then this is awesome – I don't need to either migrate to a big block of IPs I can't currently justify or add new ports to the primary firewall (and replace the secondary) for a second network drop – now I just need to find the time to reread my pfSense manual.  Well, I'll check to see if there's a current manual available...

That is something that I missing, but it does say to change dhcp settings. Probably will be in the next version.

Yup NAT reflection OR split DNS. I would choose split DNS. It is much faster than reflection.

Have to manually set the gateway to CARP address but DHCP seems to work fine.

Ahh… thanks. That was acticated too due to open op for VOIP from several clients to same external gateway. I read that was needed to have two way sound.

I think for CARP on ESX you have to have promiscuous mode turned on.

@Reiner030:

ah on which IIRC net it is? (http://www.freenode.net/irc_servers.shtml if I guess right from
http://irc.netsplit.de/channels/details.php?room=%23%23pfsense&net=freenode ?)

Hi Reiner030, good guess, see http://www.pfsense.org/index.php?option=com_content&task=view&id=64&Itemid=72.

@Reiner030:

Yes, found this type of editing also nice to get the slave easy to be cloned…
Idea/Question for this:

Would be nice to have perhaps also a cut&paste synchronization for different fw pairs with mostly same configuration. Are there special format requirements for XML ? Found editing aliases very problematic if you have dozen of IPs with comments in one big line...

I don't understand what you mean with the cut&paste sync? I think you also have clarify yourself about the special req for xml question. or just try another editor: vim? ;-)

@Reiner030:

Would be nice to have an option like in the firewall rules:

No XMLRPC Sync ( Hint: This prevents the rule on Master from automatically syncing to other CARP members. This does NOT prevent the rule from being overwritten on Slave. )

or better an option like

I am slave for this VIP

Good idea!

ok, I will try this configuration thanks for your time, when I do the changes I will let you know. Maybe on sunday I will make them, because I cannot turn down the machine on the week…

solved

i didn't get to the ios update part because i found the problem. spanning tree was converging at random times even though there was no topology changes. edited some stp costs, that did the trick.

No, I have not try to reboot them, I will try it later in the afternoon.