No idea you are obfuscating too much to see what you're actually doing.

If the switch is not learning CARP VIPs from the CARP advertisements it is probably some sort of multicast "feature" on the switch.

If the switch is receiving traffic from that MAC address it needs to:

Remove that MAC address from all other ports Add the MAC address to the port it was received on

If that is not happening, it's a problem with the switch.

That (now-deleted) reply was totally to the wrong thread. Sorry.

Well, right, you should not have a /25 on your WAN interface. You should have a much smaller subnet there and the /25 should be routed to you.

If that was the case, as strange as it sounds, .0 and .127 would be valid NAT addresses.

In order to use something other than round robin you must use type subnet.

If you can use round robin, just define a host alias using a range and NAT to that.

The backup needs to make requests to do things like check for updates.

I think the XMLRPCSync is working, there are no errors.
All changes are visible in the ipsec user interface of the second node and if I make a "diff" of the configuration-backup XML of both nodes... all ipsec changes are included in the configuration of the second node.
There must be an additional step after the XMLRPCSync which transfers the changes to "/var/etc/ipsec/ipsec.conf" and that fails or is not executed...
Because after a reboot the file is "in-sync" with the configuration.

Is it possible to change the debuglevel somewhere or add log output to the php source code?

Going to have to slow down and take things one at a time.

When you put your primary WAN interface on one address, your secondary WAN interface on another, and your CARP VIP on the third, is the Primary the CARP MASTER, and the Secondary the CARP BACKUP?

You can packet capture on your WAN to see if anyone else is using CARP/VRRP. That's pretty much the only way to know.

So this is basic port forward troubleshooting issue.

For starters RDP open to the public - Would NOT suggest!!! If you need to rdp to some server on your network, vpn into your network than access.

Please look over the troubleshooting guide
https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html

Come back if you have specific questions.. My guess off the top without any details at all would be your servers firewall... Out of the box windows sure and hell not going to allow rdp from some public IP.. Out of the box only the local network can rdp, etc.

@skullnobrains said in bidirectionnal sync:

i assume carp load sharing is a no-go as well

Correct. There is no active/active CARP, and no plans for it.

@skullnobrains said in bidirectionnal sync:

would netgate be interested into adding the feature to the stock pfsense ?

As far as I'm aware, we do not have any interest in that. We are focusing any effort in that area on working toward a proper API rather than adding to the current less-than-ideal methods.

To get around the hassle of this setup, much like my own you can always do the following:

Virtual side make the vNICS MAC for both boxes the same for the WAN interface.

I use a termination box in front of mine for VDSL and a switch before it goes into the virtual environment.

That's pritty much it. Will work, but note it will show as up on both boxes for WAN interface and the WAN graph will look a little odd on the standby box as expected.

pfSense HA/CARP is a Layer 3 failover system designed to failover in most router failure scenarios. Your vSwitch not passing traffic but having link up would be a layer 2 failure. You would need to build in redundancy at layer 2 for that.

Both the master and the slave send a lifetime of 30 seconds, which is in accordance with the value set for the AdvDefaultLifetime parameter in the automatically-generated /var/etc/radvd.conf on both boxes. However, I have set the Router Priority to Normal on the master and Low on the slave, so traffic normally always goes to the master. It's just the 30 second delay between the time the master goes down and the route disappears from the client PC that bugs me. At least with a setup where you can point to a CARP VIP (like in IPv4) and the VIP can move from the master to the slave in a split second that's a much faster failover time.

Thank You for your reply, I wasnt shure whether CARP should set VRRP MAC in ARP packagess outside FW/LAN context. Thank You for clarifying this, so we have to discuss the issue with our ISP.