Flushing the State Table solved this.

@Piba
So the actually solution was stopping HAproxy - issuing the missing certificates - and the create the frontends - and start the HAproxy again

So the prxy answering for both insa.dk and www.insa.dk

Thanks for the replys and solutions

Please describe your issue in sufficient detail.

I did select this option but all it did was prevent IMAP clients from connecting to the back-end. Could SSL on the back-end cause this?

@viragomann

Thank you anyway for your help. This allowed me to identify the problem and better diagnose a routing problem.

For my part, I carried out some test and I saw the change.
In the routing table, without a gateway, the "use" column remains at 0.

When I put the Proxmox gateway, some traffic seems to be detecting.
I think it's a routing or NAT problem.

Gateway :
gw.PNG

Route :
route ok.PNG

According to this tutorial (in French), it should however work.
The only difference is, potentially, the / 32 mask.
https://voiprovider.wordpress.com/2017/03/26/la-ha-avec-pfsense-et-1-seule-ip-wan/

I will probably create another post in the "routing" category with a link to this post.

This time I was very careful to remove the carp setting from openbgpd and to only edit the (raw) config through Services -> OpenBGPD -> Raw config (tab) on each box. It doesn't seem to have been interfered with by CARP or the other box this time round. This seems to work though I've yet to do a failover test.

It's not that you need NAT for IPv6, it's that without these specific rules, traffic bound to ::1 as a source could never leave the firewall.

that looks like solution.

Thank you for the quick response

DHCP Relay HA sync is not supported for now,
but you can create a feature request for that: https://docs.netgate.com/pfsense/en/latest/development/feature-requests.html

thank you very much, it's more clear now 👍

The best way to do an HA deployment is it invest in the gear necessary to build it correctly. Bridging like that is generally incompatible with pfSense HA.

https://docs.netgate.com/pfsense/en/latest/highavailability/layer-2-redundancy.html

As it turned out there was a loop on an interface which caused that behavior, sad but true.

After more test, the more balancer perf I can get are finally with the LRO offload check : it decrease my iperf with the firewall interface a lot (2-3Gb/s instead of 15-20Gb/s), but increase the iperf going throught the firewall, between A and B (2-3Gb/s instead or less than 500Mb/s).

I did all these test on the same ESX, so where are my speed ???