did you find any solution to this?
I am also looking for same thing.

I manually change all skew to 0 on master. On secondary sever skews changes to 100 automatically. But secondary server stop show CARP status. After reboot secondary it normally show status, and master role normally migrate from master to backup and reverse.

Thank you!

It will only work when that unit is Master. The other side should be configured to connect to the CARP VIP. They will get whichever unit is Master at the time.

Outbound NAT rules should be source-address limited to the addresses you actually want to NAT. If those are any that is almost never right.

Outbound NAT should almost always be set to have a NAT address of the CARP VIP, too. But those rules are for IPsec passthrough from clients behind the firewall, not for Site-to-site connections from the firewall itself.

Update: 2 rounds of rebooting both boxes seems to have gotten everything working.

Problem solved –- had to enable rp_filter in linux.

The first thing to check is if the secondary can resolve names, check for updates, etc while in backup status. And if not why not.

You probably want to start another thread and provide more details there.

Failover Groups I can not work like this allows me to answer.

I was with a feedback as you like.

Thanks for the reply, Derelict.

Sorry for my slow reply. I went in for surgery, and am just back on my feet again.

It is indeed unusual. I can see the connection in the state table of the master node, with TIME_WAIT:TIME_WAIT, and 9/4 packets, but the browser tells me the connection was reset, and indeed telnet to the management port is denied as well. ARP of the pfSense VIP is correct on the pinging machine, and ARP of the pinging machine is correct on the pfSense box. It seems like pfSense is blocking the connections, even though it's been told to allow them through (my allow rule uses an alias that includes the VIP and both real IPs of the pfSense boxes). Very, very strange.

I'll walk through the Network Connectivity process and see if it turns up anything.

In a last ditch effort to get things running again, I blew reset the config on FW2 and started over.  Since this is an HA pair, I just did the initial setup and had FW1 sync over the settings.  This seems to have fixed the problem.  The secondary FW is in BACKUP mode and the traffic is very minor (16KB/sec).

Not sure what happened, but something must have gone wrong during the upgrade from 2.2.6 to 2.3.2.  I might consider doing the same on FW1 (reset to factory then sync from FW2).

Thanks again for helping out!

How is your Outbound NAT configured?  I had a similar problem whereby my Outbound NAT was tied to the interface and not the VIP.  Here is what I did:

Firewall -> NAT Click Outbound NAT Make sure your "NAT Address" for the LAN subnet is tied to the external CARP IP address instead of interface address

Hope this helps.

Just a quick follow-up: we did our FW exchange last night and - at least on the CARP side - things went as expected -> VHIDs seem to work and failover just fine.

Thanks for the help! much appreciated.

As I mentioned on the first post there is a toggle to ignore suspicious Mac but it does not produces any result.

As it stands, I was forced to remove both drayteks from the network and plug the wans directly into one of my PFSENSE boxes, losing wan redundancy in the process.

I am preparing two mini-ITX pc's do replace the drayteks. One for each wan, also running Pfsense, so I can regain wan redundancy on both pfsense boxes.

cheers

It's a HP 2810-48G J9022A

pfsense is connected to port 23. Should I select MODE tagged there?

switch.PNG
switch.PNG_thumb

@Francesco:

That's fine. You weren't reading the details, exaggerating information needed and making things more difficult than they really are.

No, he was trying to point out that you could have a dozen different things wrong with your lab setup which no one can easily sort out. e.g. something on the WAN side by default can't ping your LAN, so the fact that 77 whatever can't ping 66 whatever is probably irrelevant; the 'isp router' config is unknown, etc…  I'm not sure what you are trying to test with your methodology either, someone unplugging the WAN on the master seems an unlikely event. The HA failures I've dealt with usually involve failed hardware. If I was going to test, I'd pull power on the master and see what happens. Anyway, you are seeking free assistance from strangers on the Internet. If you don't want to work with someone who steps up, fine, but don't be offended if no one else wants to spend time trying to figure out what's wrong with your setup.

Hmm. A /29 is not 8 usable IP addresses unless it's routed to you. They kind of need to get their act together.

Nope they don't. A pity but quite a few ISPs or Hosting Providers will give you 8 IPs but not route them in a clean way. Either some hack'n'slash P2P Host Routing is done or you get 8 single IPs from different segments. No one said those 8 addresses are from the same block. I know quite a few german (big) hosting companies working that way and it is annoying as hell from a networking perspective. So I won't get my hopes up until I read someone cleanly stating that it actually is a /29 IP block.