Project

General

Profile

Bug #6579

IPv6 CARP VIPs lost upon config sync where they include non-significant zeros

Added by Chris Buechler about 4 years ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Category:
CARP
Target version:
Start date:
07/05/2016
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

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.

The mwexec of ifconfig delete in xmlrpc.php is what removes it.
https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/xmlrpc.php#L311

Because it ends up being part of $oldvips array. The OS doesn't show the non-significant zeros after the IP is configured, so pfSense_getall_interface_addresses returns it that way as well. In the example case, you end up with fdaa:1234:12::1, which doesn't match fdaa:1234:0012::1, hence it's deleted.

The comparison there should use a function that takes those potential differences into account and omits from the $oldvips array.

Associated revisions

Revision 84052eb7 (diff)
Added by Viktor Gurov 5 months ago

Compare compressed IPv6 CARP VIP. Issue #6579

Revision 27e83e10 (diff)
Added by Viktor Gurov 2 months ago

Compare compressed IPv6 CARP VIP. Issue #6579

(cherry picked from commit 84052eb74b7c470ebf8fd0bb1b56ce475725b1a6)

History

#1 Updated by Phillip Davis about 4 years ago

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

#2 Updated by Chris Buechler about 4 years ago

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.

#3 Updated by Harry Coin over 3 years ago

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.

#4 Updated by Harry Coin over 3 years ago

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
"

#5 Updated by Chris Linstruth about 2 years ago

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

#6 Updated by Yaroslav Sokolov over 1 year ago

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

#7 Updated by Tobias McNulty 5 months ago

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).

#8 Updated by Viktor Gurov 5 months ago

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

#9 Updated by Jim Pingle 5 months ago

  • Status changed from Confirmed to Pull Request Review
  • Target version set to 2.5.0

#10 Updated by Renato Botelho 5 months ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • % Done changed from 0 to 100

Pull request has been merged. Thanks!

#11 Updated by Viktor Gurov 2 months ago

  • Status changed from Feedback to Resolved

successfully tested on 2.5.0.a.20200430.1700 HA cluster

#12 Updated by Jim Pingle 2 months ago

  • Status changed from Resolved to Feedback
  • Target version changed from 2.5.0 to 2.4.5-p1

#13 Updated by Viktor Gurov about 1 month ago

  • Status changed from Feedback to Resolved

works as expected on 2.4.5-p1 HA pair,
I can set fc00:3::512/64, fc00:003::512/64, fc00:0003::0512/64, etc. CARP VIP address, and it
s not deleted on config sync.

Also available in: Atom PDF