pfSense

Firstly the back-end implementation code should Net_IPv6:compress all IPv6 addresses in order to make sure the address format is "normalized" before being used for comparisons, or have a compare_IPv6 routine that does the normalize+compare or...

In order to minimize (and ultimately eliminate) the divergent forms in which IPv6 addresses are stored in the config, consider "normalizing" all IPv6 addresses on data input, so that the config always contains IPv6 addresses only in 1 standard form - see discussion in https://redmine.pfsense.org/issues/6540

Phillip Davis wrote:

Firstly the back-end implementation code should Net_IPv6:compress all IPv6 addresses in order to make sure the address format is "normalized" before being used for comparisons, or have a compare_IPv6 routine that does the normalize+compare or...

Since the OS always returns it compressed, yeah it should be sane to Net_IPv6:compress and then do the comparison.

The issue manifests as the 'backup' machine in the carp set being unable to ping6 (or otherwise pass packets to) the master active carp VIP. When that master vip happens to be the DNS provider and/or path to other related services tasks on the backup need to use... the bug generates strange apparent lockups in the gui and other great frustration because it's so 'hiding in plain sight' subtle.

The workaround is to expand all :: in ipv6 addresses.

Note this potentially related bug report:

https://github.com/opnsense/core/issues/1184
"

Adding an IPv6 CARP Virtual IP such as 1:2:3::feed appears to work but the interface does not appear to accept or respond to any packets.

Entering the IP as 1:2:3:0:0:0:0:feed allows the virtual IP/interface to work as normal
"

Possibly related: There also appears to be something not right when capital hex digits A-F are used in an IPv6 CARP VIP definition.

I have just experienced an interesting mutation of the issue. My IPv6 CARP virtual address was ending with zero: fddf:c8:4011:13:: . Writing it exactly so was not possible in "Firewall / Virtual IPs / Edit" - I got the following error message:

The following input errors were detected:

 * The network address cannot be used for this VIP

so, I had to put down fddf:c8:4011:13::0 . It caused the described problem. After changing the CARP address to fddf:c8:4011:13::100 the problem went away.

P.S. I am using the latest pfSense: 2.4.4-RELEASE-p2

Agreed, there is definitely something up with IPv6 addresses that contain capital letters. If I include such letters, it lets me assign a certain IP as a CARP IP. If I lowercase all the letters, I get an error "The broadcast address cannot be used for this VIP."

Allowing me to assign this invalid IPv6 address / subnet leads to bizarre behavior of the IP (see: https://forum.netgate.com/topic/149942/carp-ipv6-127-not-working).

Chris Buechler wrote:

If you have IPv6 CARP VIPs specified with non-significant zeros, such as fdaa:1234:0012::1, the secondary will see that as an old VIP and delete it upon config sync.

Since pfSense_getall_interface_addresses() returns compressed IPv6 addresses, the $vip address from config.xml must also be compressed by text_to_compressed_ip6() for comparison

https://github.com/pfsense/pfsense/pull/4172