Project

General

Profile

Actions
Copy link

Bug #5999

closed

IPv6 IP Alias prevents Track Interface from working with DHCPv6 and RA

Added by Abuzer Rafey over 8 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
Interfaces
Target version:
2.5.0
Start date:
03/15/2016
Due date:
% Done:

100%

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

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 fe80 (ie. if it looks like the last two outputs above), then it executes 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

Download all files
system.log (442 KB) system.log Allen Balaj, 12/03/2020 02:12 PM
2021-02-07 (1).png (130 KB) 2021-02-07 (1).png Allen Balaj, 02/07/2021 12:36 PM
2021-02-07.png (64.9 KB) 2021-02-07.png Allen Balaj, 02/07/2021 12:36 PM
2021-02-07 (3)_LI.jpg (552 KB) 2021-02-07 (3)_LI.jpg Allen Balaj, 02/07/2021 12:36 PM
Actions
Copy link
 #1

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.

Actions
Copy link
 #2

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.

Actions
Copy link
 #3

Updated by Anonymous about 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.

Actions
Copy link
 #4

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

Actions
Copy link
 #5

Updated by Jim Pingle over 6 years ago

See also: #8276

Actions
Copy link
 #6

Updated by Jupiter Vuorikoski over 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.

Actions
Copy link
 #7

Updated by Jim Pingle over 6 years ago

If it is "simple" and "not difficult", we would happily accept a pull request to fix the issue.

Actions
Copy link
 #8

Updated by Tony Fortes Ramos over 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:

  1. change the order of the IP's on the interfaces so the ULA is below the tracked IP
  2. update the radvd.conf file
  3. 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.

Actions
Copy link
 #9

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.

Actions
Copy link
 #10

Updated by Allen Balaj about 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.

Actions
Copy link
 #11

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

Actions
Copy link
 #12

Updated by Viktor Gurov about 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

Actions
Copy link
 #14

Updated by Renato Botelho about 4 years ago

  • Status changed from Confirmed to Pull Request Review
  • Assignee set to Viktor Gurov
  • Target version set to 2.5.0
Actions
Copy link
 #15

Updated by Renato Botelho about 4 years ago

  • Status changed from Pull Request Review to Feedback

PR has been merged. Thanks!

Actions
Copy link
 #16

Updated by Viktor Gurov about 4 years ago

  • % Done changed from 0 to 100
Actions
Copy link
 #17

Updated by Viktor Gurov about 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

Actions
Copy link
 #18

Updated by Renato Botelho about 4 years ago

PR has been merged. Thanks!

Actions
Copy link
 #19

Updated by Allen Balaj about 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.

Actions
Copy link
 #20

Updated by Viktor Gurov about 4 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

Actions
Copy link
 #21

Updated by Allen Balaj almost 4 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.

Actions
Copy link
 #22

Updated by Viktor Gurov almost 4 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.

Actions
Copy link
 #23

Updated by Allen Balaj almost 4 years ago

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.

Actions
Copy link
 #24

Updated by Viktor Gurov almost 4 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/

Actions
Copy link
 #25

Updated by Viktor Gurov almost 4 years ago

Return correct Track IPv6 address if >1 VIP on interface:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/124

Actions
Copy link
 #26

Updated by Allen Balaj almost 4 years ago

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?

Actions
Copy link
 #27

Updated by Jim Pingle almost 4 years ago

  • Status changed from Feedback to Pull Request Review
Actions
Copy link
 #28

Updated by Renato Botelho almost 4 years ago

  • Status changed from Pull Request Review to Feedback

Merged

Actions
Copy link
 #29

Updated by Viktor Gurov almost 4 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

Actions
Copy link

Also available in: Atom PDF