IPV6 Track Interface



  • The Track Interface feature works well but seems to limit you to /64 subnets. Without track interface, the routing is a nightmare. Is it possible with track interface to split a /64 into say two /65s, one to be handled by the PFSense interface and one to be delegated by PFSense DHCP6 as prefix for a downstream router?



  • How big of a prefix does your ISP provide?  You don't normally split a /64, as it will break SLAAC and some other things.  I get a /56 from my ISP and I can choose which /64 I use for a network.

    If you have more than a /64, then routing is easy.  You split the prefix in half and send one half to the downstream router.  You could even forward the entire prefix and longest path match will cause all traffic, except the configured /64 to be forwarded downstream.  This is basic routing.



  • I get a /56 from ISP on WAN interface. I have an OPT interface connected to a Google Wifi router. I want to delegate the entire prefix to the Google Wifi Router. Have not been able to find a working solution.



  • Can that Google router split out individual /64s?  If not, then just give it one.  You do not want more than a /64 on any network.  If it supports multiple SSIDs and VLANs, then you give a /64 to each LAN or VLAN.



  • Dont think so and dont need it to. A /64 is fine. I think I am just not understanding the "prefix delegation range" protion of the config.Nothing I plug in or try there is working.



  • @bdubn:

    Dont think so and dont need it to. A /64 is fine. I think I am just not understanding the "prefix delegation range" protion of the config.Nothing I plug in or try there is working.

    One critical point. Local networks are supposed to be only /64.  Anything else will break SLAAC.  You have an interface that connects to that Google router.  Go to the interface page for that interface.  Set it up the same way as your LAN interface, except select a different number for IPv6 Prefix ID.  Your choices are 0 to FF and the LAN is normally 0.  So, you could choose 1, FF or anything in between.  This number will be reflected in the prefix assigned to that interface.  Should that router support VLANs and multiple SSIDs, then you could add a VLAN to that interface and use a 2nd SSID for a guest network.

    BTW, is there some reason why you don't want your WiFi on the same network as your local LAN?  The last time I did that was back in the 802.11b days, when only the insecure WEP encryption was available.  Then I had the WiFi on the outside of my firewall and used a VPN to access my network.  Currently, I just have an access point, not router, connected directly to my LAN, using WPA2 for encryption.

    Also, I'm not sure you want that Google router to function as a router.  It just complicates things.  Can it be placed in bridge mode, so that it acts as just an access point?  If not, you'll have to connect it to one of the interfaces and then set up routing of another prefix to it.



  • I understand the interface config and have it configured as you described. Can you assist with the "prefix delegation range" fields on the DHCP6 service? That is what is hanging me up. I normally have the top range fields configured and understand that part. On this particular interface, I need to delegate a prefix to the Google Wifi router because it requires it. Im ok with delegating the whole /64 if possible because I do not have any other devices on the VLAN for that interface other than the Google Wifi.

    I understand your points. I went with Google Wifi strictly for a guest network solution and particularly its mesh abilities for low cost. It has some benefits for the cost, but also several drawbacks. One of these is that bridge mode basically disables a lot of features and in either mode, nothing above WPA2 Personal. Im ok with router mode, double NAT, etc for guest Wifi. The whole point is if someone compromises it, it's self contained. I will also be locking it down a little more with bandwidth limiters, maybe captive portal, etc.

    I have a separate unit/solution/SSID for internal LAN which supports WPA2 Enterprise. I would like to have IPV6 everywhere if possible though.I appreciate your help!



  • On the DHCP6 Options, I am working with a /64 that has been properly tracked from the WAN interface. In the range, I have from "::" to ::ffff:ffff:ffff:ffff:". What can I put below that in the "Prefix Delegation Range" fields that will work? If I try from "::" to "::ffff:ffff:ffff:ffff" it raises an error of "Prefix Delegation To address is not a valid IPv6 Netmask for ::/64".



  • Further, the doc at https://doc.pfsense.org/index.php/DHCPv6_Server states that the prefix delegation range would NOT be within an existing prefix on an interface (WAN, LAN, etc) and must be a routed segment.



  • Why are you using DHCP?  With SLAAC, a device will get an address based on it's MAC address.  While I haven't done this with pfSense, generally you'd configure a route for a prefix via a specified router.  What is that Google router looking for WRT IPv6?



  • No rhyme or reason other than habit and control. I have always used DHCP for IPV6 and never had an issue until now. The Google Wifi is a router and when you enable IPV^ on it, it expects to receive a prefix delegation rather than a single address. I dont suppose there would be any difference there between DHCP and SLAAC.

    I have tried specifying a different/unique /64 for the prefix delegation range. It accepts that configuration and when I go to status/dhcp6 leases, it shows what looks to be correct in that the Google Wifi was assigned an address from the /64 that is assigned to my OPT interface for Google Wifi and that a prefix is being handed to it for the other /64 that I configured for it and that that network routes to the PFSense OPT interface address. See attached screen shot.

    I get an address on the client from Google Wifi that is correct in that it matches the delgated prefix. However, it does not route. For whatever reason.




  • @JKnott:

    …is there some reason why you don't want your WiFi on the same network as your local LAN?  The last time I did that was back in the 802.11b days, when only the insecure WEP encryption was available.  Then I had the WiFi on the outside of my firewall and used a VPN to access my network.  Currently, I just have an access point, not router, connected directly to my LAN, using WPA2 for encryption.

    Guest WiFi access. Also "facebook" syndrome. Why let rogue cellphone apps inventory and probe your network.


  • Netgate

    If you have a /56 you will want to use, say, the lower network IDs, (like 0, 1, 2) as track interface settings.

    Is the google wi-fi router actually a router or is it just a wifi bridge?

    If it is a router you will want to route a prefix to it and statically assign the /64s to the backend interfaces there.

    For instance. If your assigned prefix is:

    2001:db8:23bc:4500::/56

    you could route 2001:db8:23bc:45f0::/60 to the google router and have 16 /64s to use there. You could also route 2001:db8:23bc:45fc::/62 and have 4 /64s to use there. etc.

    If it is not a router you'll want to define VLANs, assign interfaces, and use track interface for those too.

    There really is no good way to do this with a dynamic allocation. If your delegated prefix changes (which should rarely if ever happen) you will need to manually update the numbering.



  • @router_wang:

    @JKnott:

    …is there some reason why you don't want your WiFi on the same network as your local LAN?  The last time I did that was back in the 802.11b days, when only the insecure WEP encryption was available.  Then I had the WiFi on the outside of my firewall and used a VPN to access my network.  Currently, I just have an access point, not router, connected directly to my LAN, using WPA2 for encryption.

    Guest WiFi access. Also "facebook" syndrome. Why let rogue cellphone apps inventory and probe your network.

    I don't think a guest Wifi was the intent of the OP.  There's no reason why you can't have both LAN and guests on their own prefix.  Regardless, my point was there isn't much need to keep WiFi devices off of the local LAN, as WPA2 is quite secure.  That was not the case with WEP.