Project

General

Profile

Actions

Bug #8424

closed

IPv6 stops working completely for interfaces that use interface tracking and have VIPs configured on them

Added by Jupiter Vuorikoski over 6 years ago. Updated over 5 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
04/03/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.3
Affected Architecture:

Description

If you have a downstream interface configured to use a dhcpv6-pd assigned prefix (my isp gives a /56) and you have VIPs configured on the same interface (ie. fd00:dead:beef::1/64 or any prefix for that matter, even if its an actually routable one), IPv6 forwarding stops working completely for that interface.

I have rules in place that leverage alias objects containing both the pd-assigned addresses and the VIP networks since connectivity policy logic doesnt change regardless of the network used for communicating.

Reproductible: always
Workaround: remove VIPs from interface and reboot, assign vips again after reboot.
Notes: I have not tried if forwarding stops working for all interfaces or just the ones that have VIPs assigned to them. This setup is very common for segments that have a public routable prefix but also need ULA addressing for internal connectivity (this kind of setups are described in almost every deployment example published for ipv6 since 1996).

My bug https://redmine.pfsense.org/issues/8276 touches on this same issue and propably needs to be addressed for the fix at the same time since im guessing the root cause originates from the same stem.

Actions #1

Updated by Jupiter Vuorikoski over 6 years ago

Apparently after more testing, the issue does not manifest after modifying the max table size to mitigate the bogon table interfering with rules loading. However, as for why rules loaded sufficiently correctly after removing VIPs is still an issue worth investigating. My suggestion is that VIPs should be loaded somewhere just before loading rules instead of at interface up. This should be a trivial enough change to incorporate since radvd or dhcp obviously isnt reliant on having VIPs up at network-up time.

Actions #2

Updated by Jim Pingle over 5 years ago

  • Category set to Interfaces
  • Status changed from New to Duplicate

Duplicate of #5999

Actions

Also available in: Atom PDF