I've put the scripts here https://github.com/deasmi/pf_interface_pin At some point I might try to make this into a package with a UI if anyone is interested. Please note you need to re-install after an upgrade.

Yeah that should apply to all vswitches on the host. Is it all the CARP VIPs on one interface, or just one on that interface that has others that work fine?

Yes, this is normal if the firewall is the VPN server and you sync all settings from master to backup. This way the backup box has equal VPN setup and the same tunnel network exists on both, master and backup. So if the backup replies to a request from a VPN IP it sends the packet to its own VPN interface which is down though. To resolve this, you can use outbound NAT. Add an outbound NAT rule for the LAN interface, which translates IPs of packets coming from VPN tunnel network and have one of the LAN addresses of the boxes as destination (you may use an alias here or add a second rule for the other box) to its LAN address. So if you connect to the backup box over VPN, the packets get the LAN address of master and replies from backup box are sent back to the masters LAN IP and the master will route the packets to the VPN client.

I leave it enabled at defaults. It shouldn't need DPD to fail to the second node- the secondary should take over the existing IPSec connections.

This issue was fixed in 2.2.3.

One more thing I've noticed - the behaviour seems to be the same when adding new CARP VIPs. When you click save to add a VIP, it is immediately synced and applied to the secondary node, and only gets applied on the primary after clicking 'apply'. It's not so much of a problem in that case of course, because it's a new VIP, and doesn't matter if it's MASTER on the secondary initially.

Ok,…Interface Order was different on the two nodes, so the Virtual IP Synchronization was incorrect, and so it didn't work at all,...same order on both nodes, everything fine.

Just Confirmation. I did the work around and the LAGG setup is working as intended.

There's already a patch for this in 2.2.3.

I have had a similar issue, seemingly out of nowhere, with my master that was running 2.2 and my slave at 2.2.2 for a couple weeks (until Sunday afternoon).  Master affected with very slow performance, both throughput and it's own web interface.  I do not use any limiters, but I do use BGP.  I will also downgrade to 2.1.5.

Figured out my issue. port security was enabled and set to restrict on the switchport that the LAN interfaces were connected to and I could see in the switch logs that it was getting tripped. Disabled port security now all is well.

Hello, Did you find something ? I have a similar configuration and have same troubles. It's quite temporary on my side but sometimes the ping between two systems in two different vlans can go from 0.200ms to 5/15 ms without any reason. Thank you

Change the port on both primary and secondary.  That setting isn't synced.

thank you jimp I already switch to new 2.2.2 with this patch I made a short test but when I switch back to master, bgp remains in ACTIVE for 2 sessions from a total of 4 I wil make more tests on this weekend P.S: attached my old 2.0.2 uptime  8)  

We've seen that before but not lately. What version of pfSense is on both units? And do you have Captive Portal + voucher sync enabled on that cluster?

@jme: That is what i did too. @Jimp: i didn't verified, i'll check this next time and give you the log related to this action

Sorry, you've hit the limit of my knowledge on this subject.  Yes, I believe that the shared WAN IP is a Virtual IP.