Ipv6 + Track Interface + Unique Local Virtual IP = No Go ?

  • On my pfSense I have 2 VLANs: VLAN20 for my own personal use and VLAN30 for guests.

    From my provider I get a 56bit prefix, and i have now added ipv6 functionality to my pfSense and the rest of my network.
    I have set up Track Interface on both of the VLAN interfaces and i have used:
    for VLAN 30 (guests)

    • RA = Assisted
    • DHCPv6 Server on pfSense = enabled

    for VLAN 20 (me)

    • RA = Stateless DHCP
    • DHCPv6 Server on pfSense = disabled

    The VLAN30 part works as expected.

    The reason I chose a different setup for VLAN20 is because I use Microsoft Active Directory, and so DNS needs to handled by my Windows severs.
    Since I can't get a fixed IP for Internet subscription, I have no guarantee for a fixed ipv6 prefix either.
    Note: In the past 3 weeks I have no seen it change. I do know from past experiences that the ipv4 changes from time to time, although not frequently.
    At work I have the same provider, but with a business subscription.
    I do  get a fixed IP(v4) there, and a fixed ipv6 frefix after I registered my pfSense's DUID.I do not have that option on my subscription though.
    So: no guarantees…

    So, on my VLAN20 interface, I added a Unique Local subnet (a randomly selected 64 bit subnet in the FD00-range).
    I gave both my Windows servers a fixed IP in that FD-range, and told the DHCPv6-server to announce both servers with their FD-address as DNS-servers for my domain.

    I think that is the right way to do it.

    My clients computers now get both a ULA address and a Global address, as should be expected.
    As far as I can tell, everything works as intended.

    The only thing I cannot seem to do is reach my pfSense's webinterface via IPv6 by anything else but its Global address.
    pfSense itself does not have a Unique Local address, and I can't seem to get that working either.

    Once I add a Virtual IP on VLAN20 and reboot pfSense, the clients on VLAN20 no longer get their Global address.

    I removed the Virtual IP and tried a few other things:

    • I added a new VLAN interface (VLAN40) and added a Virtual IP there.
      From a VLAN20 client I CAN ping the VLAN40 ipv4 interface ( and the Global ipv6 on that interface but not the Virtual IP attached to it.
      I have no idea why that doesn't work.

    • I removed 'track interface' from the default LAN interface (which in itself isn't used anyway), and added a static FD-address instead.
      I can't ping it from a VLAN20 client, where I could ping that interface's Global address while Track Interface was still applied.

    So far, I have not found a way to access my pfSense webGUI by means of ipv6 other than a global address.
    Does anyone see what I am doing wrong? Or is it just not possible?

  • Nobody has any idea if this is possible or not?

  • I also have ULA and GUA on my LAN and pfsense does not have a ULA on the LAN interface.  It does on another one, that's ULA only.  I have no idea why it does not get a ULA on the interface when there's a GUA.  I tried manually assigning a ULA on that interface, but then things got flakey (sorry for the technical jargon  ;) ), so I removed it.

  • @klaverenboer said in Ipv6 + Track Interface + Unique Local Virtual IP = No Go ?:

    o do is reach

    I run in the same situation that the LAN-interface gets no new GUA at prefix change and so the lan clients gets no GUA as long a ULA virtuell IP ist set at LAN-Interface. Does'nt know why.

  • Got same problems, some ideas but no solution.

    If your LAN interface is set to track WAN for IPv6 it is build with a "crazy" wrapping from ifconfig

    While at commandline an "ifconfig" gives you the full set of configurated IPv6 adresses, the link in management "interfaces" just gives you TWO IPv6 adresses...exactly the Link Local(which is hardcoded for fe80::1) and ONE other IPv6 adress

    And this messes things up, cause all other things are build from this informations.

    If u set an IPv6 VIP address, these address WILL ever be the first nonLL IPv6 adress "ifconfig" sends back...and so the whole pfsense ignores all other tracked IPv6 adresses and prefixes from WAN.

    From what i ve seen there might be another (addidionally) error in VIP handling which may be influence the whole process.
    Normally the scripts filter VIP adresses, but just for IPv4 /32 and IPv6 /128...but in IPv6 cases this might be not sufficient

    The conclusion all in all is, these things kills the whole IPv6 handlings, RADVD, routing and all other configs which are build by the "generated" LAN Interface informations.

  • Add an address under Firewall > Virtaul IPs.

  • did this for ULA adress, works till firewall reboots, then the ordering changes(tracked GUA becomes the second IPv6 adress in ifconfig) and things are messed up...thats why it is a bug

    ifconfig before reboot has different ordering of adresses as after reboot, which is normal i have to say. but these behavior isnt respected in scripting of pfsense :-/

    edit: for clarification, the handling in pfsense is done by "logical" interfaces, but the creation of them has a major bug in IPv6 and how the virtual interfaces are build by informations from the physical interfaces.

    at physical layer you have the full set of IPv6 adresses an interface is configured for, but pfsense just works with two adresses in IPv6 (one is the link local adress and one is the exact first IPv6 adress after the linklocal)

    and linklocal is build hardcoded at "LAN", it deletes the nativ LL and sets to fe80::1

    have a look into function interface_track6_configure in interfaces.inc, there is imo the problem with or without an possible error in the way an VIP adress is recognized...normally any configured VIP should be ignored first and add later in process, which isnt working in IPv6 obviously

    what i ve forgot, normally u shouldnt need configuring any IPv6 VIP, per RFC an IPv6 interface can has more than one IPv6 IP, no virtual, no work around, just more than one. And so it would be making much more sense to configure it in the place the Interface will be configured normal.
    Since all routing and advertisement stuff based on the logical interface creation, it is just crazy to do it in the way it is done at the moment. It simply didnt work as it MUST work.

    No one would use an 6gear car on which you has to stay only in gears 1-4 while shifting!

  • @ulfmerbold said in Ipv6 + Track Interface + Unique Local Virtual IP = No Go ?:

    did this for ULA adress, works till firewall reboots, then the ordering changes(tracked GUA becomes the second IPv6 adress in ifconfig) and things are messed up...thats why it is a bug

    I've been running with a ULA enabled on the LAN interface for quite a while and through a few reboots and have no problem. Why is the ifconfig order an issue? It's all the same interface.

  • Since the pfsense logical interface procedure uses only two ipv6 from the underlying physical interface, after an reboot.

    As result you wont get the ip from "tracking wan" interface (is ignored since the tracking comes after an reboot when interface itself is up and running with ULA), this brakes the routeradvertisements(they are set to the ULA adress instead the needed GUA from tracking WAN interface), routingtables and much more.

    The problem isnt the ULA adress itself, the problem is, that pfsense only works with TWO ipv6 addresses...
    At commandline the ifconfig shows all IP's...but they didnt used since pfsense uses scripts for functiongeneration.

    These scripts pick the first TWO adresses...one is the LL and the other one is the first nonLL address...allothers "didnt" exists in the scripts

  • For clarification, using in the RA the ULA address is useless and because you cant config the radvd manual you comes into problems for any slaac configuration, stateful mode and so on

    The VIP address in IPv6 didnt work simply and shouldnt be needed at all, pfsense simply has to use ALL configured IPv6 addresses in all configurations. IPv6 is working only in underlying FreeBSD parts RFC compliant but its useless cause you cant configure the needed changes manual without breaking the pfsense scripts

    For IPv6 u would need an array, but its just paste an copy from IPv4 in my opinion

  • @ulfmerbold said in Ipv6 + Track Interface + Unique Local Virtual IP = No Go ?:

    For clarification, using in the RA the ULA address is useless and because you cant config the radvd manual you comes into problems for any slaac configuration, stateful mode and so on

    Well, as I said, I've had ULA up for quite a while. All IPv6 capable devices on the LAN get both GUA and ULA. When I run ip -6 addr show, on my Linux desktop, I see both address types, with the same suffix, one based on the MAC address and up to 7 based on random numbers. I also have a link local address. It just works. Are you by chance trying to assign another address to the WAN interface?

    BTW, I only use ifconfig to check addresses, etc.. I do not use it to configure anything. If you're doing that, perhaps you're creating your own problem.

  • with track interface the pfsense USES in all scripts just two of the IPv6...as i sayed ifconfig shows ALL configured IPv6 addresses

    try it out, LAN setting IPv6 Track interface , assign an VIP ULA...
    do ifconfig -a before boot you ll see
    use http://ip-of-your-pfsense/status_interfaces.php
    you see for your LAN interface before boot:
    (Only that two are shown and used for ANY configurations in pfsense)

    then do an reboot, after that log into your pfsense do same steps as described above, you will see following result

    do ifconfig -a you ll see

    use http://ip-of-your-pfsense/status_interfaces.php
    you see for your LAN interface after boot:
    (Only that two are shown and used for ANY configurations in pfsense)---->and then all configurations based on this informations are for the ashes.The RA advertises the wrong Prefix, and your clients in the back generating stupid ULA IP's and so on.

  • When I use ifconfig -a, I see:

    In the status, I see only my GUA, not ULA and LL. Regardless, that does not affect the operation. I can ping from my desktop to either ULA or GUA and ifconfig shows both. Again, the order is irrelevant, as they're all for the same interface. The reason for this is when a device does a neighbour solicitation, for ether address, the same MAC address will be returned. It that MAC address that is used for all traffic passing through that interface. It would be the same MAC, even with VLANs.

    Here's a question, can you ping either address from elsewhere on the LAN? If so, then everything is working fine, no matter what the status shows.

  • since after an reboot the GUA PREFIX disapears from RA, no device in my network generates an IP from that

    pinging ULA and LL isnt an problem, nor before and after the reboot

    and here is the point, if i would let the added VIP-ULA adress- away from LAN interface, pfsense works like intended
    but just only because you didnt has more IPv6 addresses on that logical interface

    ifconfig -a is just to test the physical interface! Ifconfig shows you only the FreeBSD parts.
    http://ip-of-your-pfsense/status_interfaces.php is my problem, here are ever only TWO IPv6 Ip's listed, and just what is listed there is used for the PFSense scripts in firewalling, RA settings and many more.

    And btw, my firewall is bare metal, no virtualisation, no "modding"...Firewall does only firewalling and DNS...and if it would work propagade the GUA prefix into inner network via RA for SLAAC usage.
    But this behavior as described is always there and cross tested with some VM's i've setup for testing. :/

    VIP in the statical IPv4 parts of the LAN interface works, in the IPv6 parts not(function interface_track6_configure in the interface.inc misses this completely)

  • So today I did a new install of pfsense 2.4.4 and played back my config. There is an ULA in virtuel IP's at LAN1 and so as discribed LAN1 gets an IPv6 from WAN via Tracking and it is shown as second in ifconfig. But RADVD is'nt working correct anymore on this Interface. It not advertises the prefix. So this is a BUG, right?