Bug #4544
closed
PD not requested if no interfaces set to track6
100%
Description
Bug #4436 disable prefix delegation requests when no tracking interface is defined. This causes a regression in combination with Network Prefix Translation in a dual-WAN setup and a Unique Local Address range on the LAN interface: pfSense requests prefix delegation from both WAN interfaces, and uses NPT to perform translation for the ULA addresses on the LAN toward the respective delegated prefixes, e.g. for load balancing or failover purposes.
In the scenario, the prefix delegation on the WAN interfaces is required, but there is no tracking interface, because the LAN interface needs to be static IPv6 with the ULA addresses.
I have such a set-up, and upgrading from 2.2 tot 2.2.1 broke IPv6 for this reason.
Can we have more control over prefix delegation, so that we can re-enable it in scenarios like this one?
Updated by Chris Buechler over 9 years ago
- Project changed from pfSense Packages to pfSense
- Status changed from New to Feedback
- Assignee set to Chris Buechler
there is a workaround for this, but I'll revisit the subject as a whole.
Updated by Chris Buechler over 8 years ago
- Subject changed from Bug #4436 causing regression on NPT setup to PD not requested if no interfaces set to track6
- Status changed from Feedback to Confirmed
- Target version set to 2.3.2
- Affected Version set to 2.2.x
updated subject is the issue. That case shouldn't cause it to skip requesting PD, for cases where the PD is actually static and people want to statically configure it, and cases like OP's with NPT.
Updated by Chris Buechler over 8 years ago
- Assignee deleted (
Chris Buechler) - Target version changed from 2.3.2 to 2.4.0
The code here is at fault.
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/interfaces.inc#L3927
It should still include the 'send ia-pd' in the dhcp6c config even if there are no track interfaces.
With a short timeline on getting a 2.3.2 out, that's not a reasonable change to make there at this point, since this is an uncommon circumstance and has risk of introducing regressions for the common circumstances.
Updated by Kill Bill almost 8 years ago
Updated by Kill Bill over 7 years ago
Can someone kindly review the PR before it's again too late even for 2.4?
Updated by Renato Botelho over 7 years ago
- Status changed from Confirmed to Feedback
- Assignee set to Renato Botelho
- % Done changed from 0 to 100
PR has been merged, thanks!
Updated by Jim Pingle over 7 years ago
- Status changed from Feedback to Resolved
- Target version changed from 2.4.0 to 2.3.4-p1
Updated by Renato Botelho about 4 years ago
- Status changed from Resolved to New
- Target version changed from 2.3.4-p1 to CE-Next
I've reverted this change in order to fix #11005. A new approach should be used for that case
Updated by Renato Botelho about 4 years ago
- Status changed from New to Resolved
- Target version changed from CE-Next to 2.3.4-p1
Patch was re-applied and this ticket remains the same