Bug #5999
closedIPv6 IP Alias prevents Track Interface from working with DHCPv6 and RA
100%
Description
I'm attempting to have GUA and ULA addresses provisioned to clients on the LAN interface by using DHCPv6 to provide GUA addresses and Router Advertisements to provide both GUA + ULA routes so that clients generate addresses via SLAAC. This is to allow for resilient IPv6 connectivity since my ISP provides a /56 over DHCPv6, which requires me to use Track Interface. Under DHCPv6 Server & RA > VLAN5 > Router Advertisements, I've added fdc0:ffee:5::1/64 to RA Subnets and switched the Router Mode to Assisted. The IP Alias is set to fdc0:ffee:5::1/64 for the VLAN5 interface.
This setup works perfectly until I reboot the pfSense machine or reset the LAN interface. This causes the IP Alias / CARP address to appear as the primary interface route and the tracked interface to appear as a secondary route (only visible by running netstat -nr
). Both DHCPv6 and RA give out ULA routes only. I suppose this would be fine if the bug occurred with a static IPv6 prefix from an HE.net tunnel because one could add the static prefix to the RA Subnet tab. Unfortunately, I've seen my DHCPv6 prefix change with a modem reboot so that wouldn't work. I tested it with 6to4 and didn't encounter this problem, so it seems to vary based on the type of interface.
I've found the output of ifconfig lagg0_vlan5 | grep inet6
to be directly correlated to the problem. Here's the output:
Before applying IP Alias to VLAN5
inet6 2600:8805:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9
After applying IP Alias to VLAN5
inet6 2600:8805:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9 inet6 fdc0:ffee:5::1 prefixlen 64
After reboot
inet6 fdc0:ffee:5::1 prefixlen 64 inet6 2600:8805:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9
After VLAN5 and/or WAN reset
inet6 fdc0:ffee:5::1 prefixlen 64 inet6 fe80::1:1%lagg0_vlan5 prefixlen 64 scopeid 0x9 inet6 2600:8805:5::1 prefixlen 64
I don't know much about how BSD/pfSense decide which IPv6 route to pass onto radvd or which prefix to use for DHCPv6 clients but as a temporary workaround I'm using a script that runs ifconfig lagg0_vlan5 | grep inet6
every minute. If the line containing inet6 fdc0
occurs before the line containing inet6
(ie. if it looks like the last two outputs above), then it executes fe80
ifconfig lagg0_vlan5 inet6 fdc0:ffee:5::1 prefixlen 64 -alias && ifconfig lagg0_vlan5 inet6 fdc0:ffee:5::1 prefixlen 64 alias
to force the ULA address/route to the bottom, which gets DHCPv6 and radvd working correctly so I think that the problem lies here somewhere.
Hopefully this helps.
Files
Updated by Chris Buechler over 8 years ago
- Category set to Interfaces
- Status changed from New to Confirmed
- Affected Version changed from 2.3 to All
find_interface_ipv6 returns the first IP on the interface in that case, which might not be the intended one in that situation.
Updated by Anonymous over 8 years ago
Another issue that seems to be related to this is that firewall rules using "LAN net" and similar are not obeyed if you have multiple subnets with the ULA Virtual IPs. The code that generates the firewall rules appears to only be using the primary IPv6 address, which is the public prefix from track6. It looks like the code needs to handle all the IPv6 addresses on the interface and not just the first one, both for DHCPv6/RA and for generating firewall rules.
Updated by Anonymous almost 8 years ago
Any update on this? I would really like to be able to use ULA and GUA IPv6 addresses at the same time on my network, but this issue prevents me from doing so by making the GUA stop working whenever the router is rebooted.
Updated by Doug Twitchell over 7 years ago
Fixing this would help with the problems discussed in this forum post: https://forum.pfsense.org/index.php?topic=126978.0
Updated by Jupiter Vuorikoski about 6 years ago
Did not realize that there was an issue as old as this when i first made my own tickets. This affects every version of pfsense until the very latest. The fix would be as simple as to not treat Virtual IPs as candidate addresses for actual configuration daemon and instead wait for tracked addressing to come up before writing radvd and dhcpd config.
This would NOT be difficult to implement and dismissing it as something to be addressed in the unforeseeable future is just shameful.
Updated by Jim Pingle about 6 years ago
If it is "simple" and "not difficult", we would happily accept a pull request to fix the issue.
Updated by Tony Fortes Ramos about 6 years ago
Jim Pingle wrote:
If it is "simple" and "not difficult", we would happily accept a pull request to fix the issue.
Well, I really don't know how to cleanly fix this, but from what I have seen, three steps are needed to fix it:
- change the order of the IP's on the interfaces so the ULA is below the tracked IP
- update the radvd.conf file
- restart radvd
The first and last steps I can do with my ULA IP's hardcoded into a script. Sadly, I cannot figure out how to regenerate the radvd config file.
Updated by Chris Linstruth over 5 years ago
As far as I can tell there are too many assumptions placed on the order of the addresses on the interfaces.
There are two things in play that I see:
1. Generation of radvd.conf
2. Generation of pass "LAN interface" rules.
If the GUA from track interface is the first one listed in ifconfig, everything seems to work fine.
If the ULA address is listed first, everything pretty much breaks.
With a dynamic prefix delegation, even a relatively-stable one, standard practice is to use both ULA and GUA on inside interfaces as outlined in RFC7368 3.4.2.
Updated by Allen Balaj almost 5 years ago
I encountered this issue while attempting to host internal web services via IPv6 using a dynamic external IP address. My experiences are described in this forum post: https://forum.netgate.com/topic/138257/cannot-ping-pfsense-ula-from-subnet-without-ula-assigned-to-firewall.
I am a software developer, albeit absent any pfSense-specific insights, and would be willing to help craft a pull request if enough developers were interested in trying to resolve this. I think it will be challenging to resolve because it seems like there are still many places in the code base where it operates under the assumption that there will be only one primary address per interface as is the norm with IPv4 instead of the multiple addresses per interface as is the norm with IPv6. Together with the lack of dynamic NPT (https://redmine.pfsense.org/issues/4881), this means that IPv6 services cannot be hosted externally without a static IP address.
Updated by Rick Coats over 4 years ago
Jim Pingle wrote:
If it is "simple" and "not difficult", we would happily accept a pull request to fix the issue.
I don't know FreeBSD, but isn't there a route command to just add the additional static route to the interface without creating a VIP?
You don't need a VIP since they are both on the same link and the gateway for both of these prefixes is already defined to be fe80::1:1 anyway. If you look at the RA it is advertising itself for both subnets on the link local when you add the additional subnet on the Router Advertisements tab.
Say in your routes it shows:
2001:db8:abcd:dcba::/64 link#6
you just need to add a route for the added prefix so that you get:
2001:db8:abcd:dcba::/64 link#6
fdc0:ffee:5::1/64 link#6
The actual gateway is done by:
fe80::%hn1/64 link#6
fe80::1:1%hn1 link#6
Updated by Viktor Gurov almost 4 years ago
Another issue that seems to be related to this is that firewall rules using "LAN net" and similar are not obeyed if
you have multiple subnets with the ULA Virtual IPs. The code that generates the firewall rules appears to only be using
the primary IPv6 address, which is the public prefix from track6. It looks like the code needs to handle all the IPv6
addresses on the interface and not just the first one, both for DHCPv6/RA and for generating firewall rules.
Fixed in #8256
What about main issue, pfSense_get_interface_addresses() needs to be improved to return all addresses or return the first non-vip address
Updated by Viktor Gurov almost 4 years ago
Updated by Renato Botelho almost 4 years ago
- Status changed from Confirmed to Pull Request Review
- Assignee set to Viktor Gurov
- Target version set to 2.5.0
Updated by Renato Botelho almost 4 years ago
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
Updated by Viktor Gurov almost 4 years ago
- % Done changed from 0 to 100
Applied in changeset 391ffd740ff73339a00ab4b988660e12bfa69cfe.
Updated by Viktor Gurov almost 4 years ago
fixes/improvements:
- Show Track6IP correctly if there is no VIPs on the interface;
- Show PD on the `services_dhcpv6.php page`:
"Subnet Prefix Delegation (2001:db8:1111:fff0::/60)"
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/35
Updated by Allen Balaj almost 4 years ago
I can confirm that this seems to resolve the original problem that I was experiencing. Really appreciate the fix guys! Any chance we could get a dropdown to specify which prefix to use for the DHCPv6 server? In my network I use DHCPv6 to assign ULA addresses but the servers receive their global address via RA's.
Updated by Viktor Gurov over 3 years ago
Allen Balaj wrote:
I can confirm that this seems to resolve the original problem that I was experiencing. Really appreciate the fix guys! Any chance we could get a dropdown to specify which prefix to use for the DHCPv6 server? In my network I use DHCPv6 to assign ULA addresses but the servers receive their global address via RA's.
Please create a new feature request for this
See also #10715 and #10714
Updated by Allen Balaj over 3 years ago
Thanks Viktor, I'll keep an eye on those feature requests. That said, I may have spoken too soon regarding this fix working as intended. With the latest nightlies, I am again seeing my GUA prefix drop off the LAN interface after a reboot. Let me know if you need any system-specific info.
Updated by Viktor Gurov over 3 years ago
Allen Balaj wrote:
Thanks Viktor, I'll keep an eye on those feature requests. That said, I may have spoken too soon regarding this fix working as intended. With the latest nightlies, I am again seeing my GUA prefix drop off the LAN interface after a reboot. Let me know if you need any system-specific info.
Works fine for me. What is your current pfSense snapshot version?
Please attach system.log and brief info about your interfaces.
Updated by Allen Balaj over 3 years ago
- File system.log system.log added
I'm currently on 2.5.0.a.20201124.0050. My firewall is single LAN, single WAN, ~2 dozen VLANs, running atop a Proxmox VM with 2 virtualized network interfaces. See my system.log attached.
My LAN subnet is the only VLAN that I have currently have configured to advertise both the ULA and GUA prefixes, along with the corresponding VIP for routing.
Updated by Viktor Gurov over 3 years ago
Allen Balaj wrote:
I'm currently on 2.5.0.a.20201124.0050. My firewall is single LAN, single WAN, ~2 dozen VLANs, running atop a Proxmox VM with 2 virtualized network interfaces. See my system.log attached.
My LAN subnet is the only VLAN that I have currently have configured to advertise both the ULA and GUA prefixes, along with the corresponding VIP for routing.
Unable to reproduce, it works fine for me on 2.5.0.a.20210204.2250
You issue may be related to receiving DHCP6 packets on boot:
Nov 21 05:15:36 pfSense php[407]: rc.bootup: Unbound start waiting on dhcp6c. Nov 21 05:15:37 pfSense php[407]: rc.bootup: Unbound start waiting on dhcp6c. Nov 21 05:15:38 pfSense php[407]: rc.bootup: Unbound start waiting on dhcp6c. Nov 21 05:15:39 pfSense php[407]: rc.bootup: Unbound start waiting on dhcp6c. Nov 21 05:15:40 pfSense php[407]: rc.bootup: Unbound start waiting on dhcp6c. Nov 21 05:15:41 pfSense php[407]: rc.bootup: Unbound start waiting on dhcp6c.
Please create a forum topic with detailed description on https://forum.netgate.com/
Updated by Viktor Gurov over 3 years ago
Return correct Track IPv6 address if >1 VIP on interface:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/124
Updated by Allen Balaj over 3 years ago
- File 2021-02-07 (3)_LI.jpg 2021-02-07 (3)_LI.jpg added
- File 2021-02-07 (1).png 2021-02-07 (1).png added
- File 2021-02-07.png 2021-02-07.png added
Hey Viktor,
Thanks for the update. Given your feedback, I was able to download the latest snapshot and re-test this. It doesn't seem to have changed the behavior that I'm seeing. After adding the VIP and rebooting, the LAN IP address and prefix immediately changes to that of the VIP in both the Interface Status page as well as the DHCPv6 and RA settings page for the LAN subnet. I'm attaching some screenshots here to help you understand what's going on. Once I remove the VIP, the v6 address and prefix both return to the delegated range assigned via the WAN link.
I didn't quite understand what you meant by the DHCP6 packets on boot. Are you saying that the DHCP6 packets sent out by the firewall are causing pfSense to prioritize the VIP prefix? If that's the case, shouldn't it only affect any clients receiving such a packet? To be clear, my issue is with the information being displayed on the firewall web interface, not client side. I'm not currently aware of any discrepancy between what the firewall claims to be advertising and what the clients are assigning to themselves.
I have my long running forum thread that I created for this issue, but it hasn't received much feedback other than people reporting the same problem. It can be found at https://forum.netgate.com/topic/138257/ipv6-ip-alias-prevents-track-interface-from-working-with-dhcpv6-and-ra/. I'll update that thread to see if I can solicit any more feedback, but we could be waiting for quite some time. Is there any way that I can generate a memory dump or stack trace that might help you analyze this further?
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to Pull Request Review
Updated by Renato Botelho over 3 years ago
- Status changed from Pull Request Review to Feedback
Merged
Updated by Viktor Gurov over 3 years ago
- Status changed from Feedback to Resolved
my test:
DHCPv6 server with fc00:623:5::-fc00:623:50:: /52 PD
pfSense 2.5.0.r.20210211.1637 client with two IP Aliases on the LAN (track) interface:
fc00:1111::1 and fc00:2222::2
After receiving PD it also has the fc00:623:50:0:4c49:f0ff:fefe:bf12 address:
# ifconfig vtnet0 vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: LAN options=800b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> ether 4e:49:f0:fe:bf:12 inet6 fe80::4c49:f0ff:fefe:bf12%vtnet0 prefixlen 64 scopeid 0x1 inet6 fe80::1:1%vtnet0 prefixlen 64 scopeid 0x1 inet6 fc00:1111::1 prefixlen 64 inet6 fc00:2222::2 prefixlen 64 inet6 fc00:623:50:0:4c49:f0ff:fefe:bf12 prefixlen 64 inet 192.168.88.41 netmask 0xffffff00 broadcast 192.168.88.255 media: Ethernet 10Gbase-T <full-duplex> status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
After configuring RA and DHCPv6 on the LAN interface it has correct configuration with PD address:
# cat /var/etc/radvd.conf # Automatically Generated, do not edit # Generated for DHCPv6 Server lan interface vtnet0 { AdvSendAdvert on; MinRtrAdvInterval 5; MaxRtrAdvInterval 20; AdvLinkMTU 1500; AdvDefaultPreference medium; AdvManagedFlag on; AdvOtherConfigFlag on; prefix fc00:623:50::/64 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvValidLifetime 86400; AdvPreferredLifetime 14400; }; ...
# cat /var/dhcpd/etc/dhcpdv6.conf option domain-name "lab.int"; option ldap-server code 95 = text; option domain-search-list code 119 = text; default-lease-time 7200; max-lease-time 86400; log-facility local7; one-lease-per-client true; deny duplicates; ping-check true; update-conflict-detection false; authoritative; subnet6 fc00:623:50::/64 { range6 fc00:623:50::100 fc00:623:50::200; do-forward-updates false; #option dhcp6.name-servers --; } ddns-update-style none;
all OK after reboot