Perfect - thanks so much

@jimp

Thanks i didnt find this.

bolvar

Ah thanks :) That clears it up pretty much. Never actually ran into that issue besides static mappings and that is no problem in a cluster that I'm aware of ;)

You could always pull the vip out of the config, and then reload it.

Backup, edit xml to remove the vip, restore the backup.

Thank you for your answer.

Thanks for the input. I have examined it further. It needs to be enabled in Hyper-v vswitch MAC-spoofing, then it works.

Thank you!

Packet capture on the WAN. If the traffic arrives but there is no response (there will be) it's something on the firewall.

If the traffic doesn't arrive (it will start with ARP traffic) then it's something in your virtual infrastructure, switching, etc.

@Derelict Just wanted to let you know know it's looking allot better now and I think it was just that lingering interface that should have been down that caused the issue (which then caused others).

Thanks for coming back so quick on a Sunday. FYI, I've now hit another Intel 10G known issue which I'll post once I re-read the previous ones

@Derelict
Super. Fine. Exactly what is needed !

Fixed by properly NAT-ing the requests:
pfsense active - IP x.x.x.2/24
pfsense standby - IP x.x.x.3/24
pfsense CARP - IP x.x.x.1/24

Create NAT Outbound:

Interface LAN_MGMT Source - my client LANs Destination - pfsense IP from above (subnet x.x.x.x/30) NAT Address - LAN_MGMT address

Works like charm.

Brilliant! Thank you very much!

Thanks for the tips! This resolved the issue!

We created a lab with two firewalls with very basic configs, and set up something similar to what I outlined above. I provided rules and config to @Derelict at the beginning of July and messaged him since to follow up but haven't heard back. So, I'm uploading them here.

Using these configs, the IP address in the test alias (from the outside/WAN interface of the firewall) can connect to the secondary firewall's LAN interface, even though the rules would seem to block it.

Additionally, any IP address on the LAN subnet can connect to the secondary firewall's WAN address, even though the rules would seem to deny it.

If you turn off state syncing, this stops being true.

I'm interested to see if anyone can find an issue with how the config is set up, or whether using "This firewall" in the rules just isn't enough to ever block access on the secondary.

fwa_rules.debug.txt
fwb_rules.debug.txt
config-fwa.localdomain-20190627095630.xml
config-fwb.localdomain-20190627100039.xml

@agterry said in HA Dual-WAN Issues with Packet Loss:

failover a VPN tunnel as well if possible

IPSEC or OpenVPN? And by failover that means from WAN1 to WAN2 or just from master node to slave node?

It is possible but you must use things like Spanning Tree to prevent loops. HA + Bridging is not a recommended configuration.

Much better is to have your ISP issue you a small WAN interface network (/29) and route the subnet to that.

Then you can put the public subnet on an inside interface, eliminate all bridging and NAT, and your network will just make money while you sip margaritas by the pool.

Solved. I use IKEv2 now.

@Derelict said in HA Sync problems since updating to 2.4.4:

explicit-exit-notify does not apply in that case because the OpenVPN instance does not exit on failover. That means the clients will have to time out and when they attempt to reconnect they'll get whatever system holds the CARP VIP at that time.

Ah thanks for adding that. So would only work on a VPN configured on a failover gateway group type of WAN?

Edit: Also we got the problem to appear less now by adding the "no monitoring at all" switch to all 15 VPN gateways. But:

that eliminates the possibility for a some grouping of VPN interfaces that blocks monitoring and status/availability checks on those gateways is irritating to the admin staff (as all VPNs are always "on" even if they won't work)

etc.
We can definetly track that down to something that changed since 2.4.4 as with 2.4.3 and ~6-7 VPNs active at the time (with their gateways configured active) that problem didn't happen at all.

So situation is:

with 2.4.4 - whysoever - VPN GWs assigned and configured are "tilting out" the standby node even without gateway monitoring, the standby node spits out ~300 lines of syslog with every config save on the master as every single VPN interface is set down, then up, then reconfigured, then detected with a "new IP" (even if that didn't change at all) etc. etc. all that starts after every simple config change

I understand the config sync to be non-trivial, but it strikes me odd, that changes to aliases or rules have to trigger that whole bunch of interface action just to reload and activate some simple ruleset or alias changes?

Thanks for any insight,
Jens

On a healthy system the primary would be showing skew 0, the secondary skew 100.

Check the system log for entries related to why it is changing the skew to 254.