PFSense Not Working with DHCPV6 or Stateless on tracking interface



  • I have a pfsense netgate SG8860
    Occasionally, Comcast does this wonderful thing of changing my business-class ipv6 network address.

    To counteract that headache, I'd like to automate the change.

    I setup my wan interface to DHCPv6
    Works great
    I setup my lan interface to track the wan interface
    Works great
    I can setup a static IP on my desktop and connect to the public internet, just fine
    Router advertisement doesn't work.
    DHCPv6 doesn't work.

    If I move the interface from tracking interface, to static ipv6 with the same exact IP it was on previously both DHCPv6 and Router Advertisement work immediately with no other changes.

    If I have tracking interface set:
    If I manually set a subnet for router advertisement, everything works.
    For dhcpv6, Instead of seeing a specific available range, it says "Available Range :: to ::ffff:ffff:ffff:ffff" which is clearly not right.

    Am I doing something wrong?
    Is this a bug? If yes, what is the best way to have this addressed?



  • Set the range to something like this:

    ::eeee:0000:0000:0001 to ::eeee:ffff:ffff:ffff

    That's based on a /56 prefix.



  • @marjohn56:

    Set the range to something like this:

    ::eeee:0000:0000:0001 to ::eeee:ffff:ffff:ffff

    That's based on a /56 prefix.

    Can you explain that one a bit?



  • No…. 8)

    Ok, it's effectively the same as setting the dhcp range in IPV4, only much much bigger.

    In v4 you would set a range say from 192.168.1.100 to 192.168.1.200, and dhcp would give out addresses in that range.

    V6 is the same. The prefix from the ISP may be 48,56,60 whatever, and that is the first 'n' bits of your ipv6 address, you can do what you like with the rest.

    So in the example I gave, my prefix is /56, I have an prefix like so: 2a12:2c7f:6130:4d ( not my prefix! ) that's my 56 bit prefix. I then have 128-56 bits to play with, that gives me 72. 72.

    Now, my LAN side is really a 64 bit prefix, as the 8 bits after the 56 ISP assigned prefix gives you the option of upto 256 ( or is it 255 ) separate routers should you so wish chained on to the first router.

    So we use the last 64 bits as our range on the LAN, a bit excessive I know but it allows you to have loads of fridges, toasters and the IoT all connected. So then we see the last 64 bits of the range are:

    ::eeee:0000:0000:0001 to ::eeee:ffff:ffff:ffff,

    What we are saying there is, the last 64 bits by the :: at the start, everything else prior to that will be either the prefix or 0. If you really wanted you could have a range of
    ::0000:0000:0000:0001 to ::0000:0000:0000:00fe, giving you 254 addresses, but that would be silly. Even so, I am limiting the range a little by making everything on my LAN ( that uses a dhcp6 assigned address ) start the last 64 bits with eeee, thus limiting the number of dhcp addresses on my LAN to 281474976710655 addresses, not going to run out this week.

    Does that make sense or is it gibberish, I understand it bit explaining it is never simple.



  • I get what you're trying to say now, but that doesn't really resolve my problem.

    DHCPv6 isn't getting a network address, and neither is stateless autoconfig, on a tracking interface.

    You're giving me a host address range.

    I need to know how to get an automated network address on a tracking interface.

    The host address part is easy to deal with.



  • You need to enter the address range, it's not telling what the range is, it's giving you you the limits of the range you can use.



  • @marjohn56:

    Set the range to something like this:

    ::eeee:0000:0000:0001 to ::eeee:ffff:ffff:ffff

    That's based on a /56 prefix.

    It doesn't matter what size the prefix is (as long as it's at least a /64). The range is /64 from :: to ::ffff:ffff:ffff:ffff. The bits that fill in the difference between the prefix and /64 are prefix id, in the lan settings.



  • @bimmerdriver:

    @marjohn56:

    Set the range to something like this:

    ::eeee:0000:0000:0001 to ::eeee:ffff:ffff:ffff

    That's based on a /56 prefix.

    It doesn't matter what size the prefix is (as long as it's at least a /64). The range is /64 from :: to ::ffff:ffff:ffff:ffff. The bits that fill in the difference between the prefix and /64 are prefix id, in the lan settings.

    What prefix ID in the LAN Settings, where's that then? It would be different if it was a /48 prefix, unless you wanted 65k+ subnets.  :P



  • Well, it's up to 8 bits, not that anyone would ever have that many subnets. The rest would be for delegated prefixes. But the point that the dhcpv6 subnet range is 64 bits is the same, irrespective of whether your ISP gave you a /56 or some other size of prefix.



  • We're arguing semantics here, I say potato you say poTAto type thing, the ops issue was he had not entered anything.



  • Lets ignore dhcpv6 entirely for a moment.

    I want to know:
    why I can't get an ipv6 address from router advertisement on my box when I have tracking interface used, with unmanaged router advertisement

    while

    I can get an ipv6 address from router advertisement on my box when I have when I have static interface set to the same IP that would be used by tracking interface, with unmanaged router advertisement turned on



  • This is what happens to my pfSense in this scenario with a nightly change of the WAN address: The LAN interface gets a global IPv6 address once directly after setting it to track the WAN interface but never again when the WAN interfaces's address changes. Looks like the tracking doesn't work. And then the router advertisements obviously cannot work either.



  • @moscato359:

    Lets ignore dhcpv6 entirely for a moment.

    I want to know:
    why I can't get an ipv6 address from router advertisement on my box when I have tracking interface used, with unmanaged router advertisement

    while

    I can get an ipv6 address from router advertisement on my box when I have when I have static interface set to the same IP that would be used by tracking interface, with unmanaged router advertisement turned on

    Don't know, but I set mine to assisted and have never had a problem. That way the client can decide what they want either way,



  • @pFence:

    This is what happens to my pfSense in this scenario with a nightly change of the WAN address: The LAN interface gets a global IPv6 address once directly after setting it to track the WAN interface but never again when the WAN interfaces's address changes. Looks like the tracking doesn't work. And then the router advertisements obviously cannot work either.

    Why would the wan interface address change?

    dhcp6c should be sending renew signals. What is your dhcp log showing with respect to dhcp6c?

    This is what mine looks like, OK my dhcp6c is modified to give more info and the interface.inc is different but the process of renew is pretty much the same except it says renew. In fact with the newer dhcp6c and interface.inc the call to rc.newwanipv6 does not get called on renew and my system runs solidly as do many others.

    Can you give some more information rather than just saying it does not work. Do you need to set 'Do not wait for a RA' or not, what is the refresh time of your ISP? If you run dhcp6c in debug mode it will give you all the information you need to decide if the problem is there or not.

    If the lease is not being renewed then you have a problem, but the first thing to do is to find out what the renew time should be and look at the logs around that time and see what's happening.



  • @marjohn56:

    Why would the wan interface address change?

    Comcast claims I have a static ipv6, but I've seen the network ID change.
    Why they change me occassionally, I don't know.
    It's really annoying.

    I don't want to risk a situation where the network ID changes, and then the ipv6 network goes down when I'm not there.

    If I have a tracking interface, with working unmanaged RA, it'll be self healing.

    With tracking interface:
    If the network address changes, then the router advertisement changes, which then the local host ipv6 address changes.

    It's a safety net.



  • I've never known an ISP to change a static without advising the client first, it would cause absolute havoc.

    It sounds like you have a 'Sticky' static address, which can be made even more sticky by fixing the DUID and IAID, as the IAID does is fixed with pfSense ( at present ) that will not change. I suggest you set your DUID to fix it at its current value. You can also turn on 'Do not send release' which will prevent dhcp6c from sending a release signal, some ISP's will give you a new address/prefix if they get a release signal. However as Comcast say you are on a static  this should not happen either.

    I have a sticky dhcp6 address, through experimentation it's been found that if both the above are carried out, fixing the DUID and never sending a release signal then the prefix never changes, the only side note would be if pfsense went offline for several days, in which case I 'might' get a new prefix.



  • @moscato359:

    Comcast claims I have a static ipv6, but I've seen the network ID change.

    Google searches still show that Comcast does not support static ipv6 addressing. My ipv6 address changes every time they put in a new modem. My ipv4 address is unchanged across all the supplied modems.

    Don't expect a static any time soon. The 'static' problem is supposed to be taken care of by DNS when the router and DNS providers get it all working. "Services, DHCPv6 Server & RA, LAN, DHCPv6 Server, Dynamic DNS Display" is the new static in it's early stages.

    I don't want to risk a situation where the network ID changes, and then the ipv6 network goes down when I'm not there.

    If I have a tracking interface, with working unmanaged RA, it'll be self healing.

    No it won't. Try repowering the modem with a switch in between the router and the cable box so the router can't sense link down. The address won't change but connectivity will be lost.

    NATv6 FTW until this problem is fixed.



  • You can also turn on 'Do not send release' which will prevent dhcp6c from sending a release signal, some ISP's will give you a new address/prefix if they get a release signal.

    Where is that setting?  I sometimes get a new prefix and in testing I could see pfSense send a DHCPv6 release after I disconnected and reconnected the WAN Ethernet cable.  My DUID has not changed since last May.  I'm on Rogers.



  • @JKnott:

    You can also turn on 'Do not send release' which will prevent dhcp6c from sending a release signal, some ISP's will give you a new address/prefix if they get a release signal.

    Where is that setting?  I sometimes get a new prefix and in testing I could see pfSense send a DHCPv6 release after I disconnected and reconnected the WAN Ethernet cable.  My DUID has not changed since last May.  I'm on Rogers.

    Interfaces/WAN/DHCP6 Client Configuration - Do not allow PD/Address release.

    DUID hold is in System/Advanced/Networking.



  • I don't see that, even under Advanced Configuration.  I'm running pfSense 2.3.2_1.



  • DHCP6 Client Configuration, 2.4B ;)

    "Do not allow PD/Address release"
    "dhcp6c will send a release to the ISP on exit, some ISPs then release the allocated address or prefix. This option prevents that signal ever being sent"



  • @hda:

    DHCP6 Client Configuration, 2.4B ;)

    "Do not allow PD/Address release"
    "dhcp6c will send a release to the ISP on exit, some ISPs then release the allocated address or prefix. This option prevents that signal ever being sent"

    Did I fail to mention that… Beg pardon  8)



  • DHCP6 Client Configuration, 2.4B

    There's a version 2.4B???

    I'm supposedly at the latest and I don't see that setting anywhere.



  • DUID hold is in System/Advanced/Networking.

    I don't see that one either.  My version of pfSense must have come from a parallel universe or something, as it doesn't appear to have either of those settings.



  • It's a setting in the pfSense 2.4 beta.



  • I'll have to watch for that new version.  Any idea when it will be available?



  • @JKnott:

    I'll have to watch for that new version.  Any idea when it will be available?

    For several months now… Its in beta but its very stable. Either install from clean, my preference, or you can select 2.4 as you should find it in update/update settings.



  • You can also turn on 'Do not send release' which will prevent dhcp6c from sending a release signal, some ISP's will give you a new address/prefix if they get a release signal.

    I've found that in v2.3.3 and have set it.  Hopefully it works, so my prefix won't change simply because I unplugged my Ethernet cable.

    Incidentally, why did pfSense send a DHCPv6 release when the computers was merely disconnected from the modem & reconnected?  I could see that happening when I monitored the connection with Wireshark.  A release is something that should be specifically requested and not occur for something as trivial as a disconnect/reconnect.



  • @JKnott:

    You can also turn on 'Do not send release' which will prevent dhcp6c from sending a release signal, some ISP's will give you a new address/prefix if they get a release signal.

    I've found that in v2.3.3 and have set it.  Hopefully it works, so my prefix won't change simply because I unplugged my Ethernet cable.

    Incidentally, why did pfSense send a DHCPv6 release when the computers was merely disconnected from the modem & reconnected?  I could see that happening when I monitored the connection with Wireshark.  A release is something that should be specifically requested and not occur for something as trivial as a disconnect/reconnect.

    Because dhcp6c exits and on exit it sends a release, hence the addition of the no-release flag and an updated dhcp6c client.



  • The question is why it sends the release by default.  With IPv4 DHCP, a device normally requests the same address on re-connection and gets it if available.  You have to specifically request a release.  Why shouldn't it be the same with IPv6?



  • @JKnott:

    The question is why it sends the release by default.  With IPv4 DHCP, a device normally requests the same address on re-connection and gets it if available.  You have to specifically request a release.  Why shouldn't it be the same with IPv6?

    Because it's a totally different client and bears little resemblance to its v4 counterpart.



  • DHCPv6 has something called "DUID" the purpose of which is to identify the client so it get the same prefix.  Having the default release means that no longer works.  With IPv4, a changed address could affect a single device, but on IPv6 at least a /64, but often more, affecting potentially gazillions of addresses.  When the prefix changed, I had to go and update all the DNS entries for devices on my network, even if I did nothing more than connect in a managed switch, so that I could monitor the traffic with Wireshark.  I don't think the release should be happening, unless specifically requested, as happens with IPv4.



  • That's why it's been modified along with the DUID stored in the config.



  • I've found that in v2.3.3 and have set it.  Hopefully it works, so my prefix won't change simply because I unplugged my Ethernet cable.

    It appears to work.  I have disconnected/reconnected the WAN cable several times since yesterday.  My prefix stays the same and I'm not seeing any DHCPv6 release.



  • @JKnott:

    I've found that in v2.3.3 and have set it.  Hopefully it works, so my prefix won't change simply because I unplugged my Ethernet cable.

    It appears to work.  I have disconnected/reconnected the WAN cable several times since yesterday.  My prefix stays the same and I'm not seeing any DHCPv6 release.

    :) That's OK then.

    I began the work on dhcp6c almost a year ago when my ISP rolled out IPv6. There were quite a few issues to deal with, dhcp6 before RA being the first. Then there was loss of PD when ever the connection dropped, partially corrected by the no-release flag but if you ran a RAM drive then the DUID would change, this could be avoided by using an early shell command to copy the DUID from the drive to the RAM at boot, but it was still not held in the config; this was done a couple of months back. We are now awaiting a further PR to be accepted upstream which adds a few other features missing from dhcp6c. I and my testers are running it and we now have VERY quiet logs.



  • I'll keep an eye on it for a while.  If it fails again, I'll report back.



  • It's been tested to death for the last 'n' months, solid as a rock. The only time we see any change in PD now is when the ISP resets their servers, and there's nothing we can do about that.



  • I just posted a message about this on a forum for customers of my ISP (Rogers).



  • I'm one of the people who has been testing these features since marjohn56 started to develop them. I'm on Telus and there are other Telus users who have also been using these features. I started a thread in www.dslreports.com/forum/telus about it.



  • I can confirm the changes in 2.4b by marjohn work wonders, on sky UK, it works with perfection now.