[Solved] DUID woes

  • Dear Forum

    Situation: My provider offers static IPv6 prefixes which are assigned based on the client's DUID.

    Now here are two troubles I have with the way pfSense handles DUID:

    a) Bad: It cannot be backuped/restored or cloned
    Sure, I can copy the file /var/db/dhcp6c_duid off the old box and copy it to a new box. If I then restart dhcp6c, it will announce that cloned DUID. However, after a reboot pfSense will regenerate a "static" DUID. So after every reboot, I would have to copy the dhcp6c_duid file back and manually restart dhcp6c. This is not a serious option for professional use.

    b) Worse: It changes after software updates and every reboot
    Today I updated my pfSense installation from 2.3.1_1 to 2.3.1_5. The result: pfSense suddenly generates a new, different DUID upon reboot! AAAAAAAAARGH!

    The result: one way or the other, after rebooting my firewall I risk losing my IPv6 prefix, must annoy my provider's support and wait a day or so until they find the time to update the settings on their side. This is ultra annoying and really spoils the fun of using an appliance such as pfSense.

    What solutions can the community provide? Not updating pfSense, not changing the hardware platform and never rebooting the system are obviously no valid suggestions.

  • Here's my solution including some tinkering:

    Log into pfSense via SSH.

    cd /conf
    mkdir dhcp
    cp /var/db/dhcp6c_duid .

    Now log into pfSense through Web Admin:
    In the menu go to: System -> Package Manager -> Available Packages
    Install package "Shellcmd"
    In the menu go to: Services -> Shellcmd

    Add new shellcmd:
    Command: cp -f /conf/dhcp/dhcp6c_duid /var/db/
    Shellcmd Type: earlyshellcmd
    Comment: Fix braindead IPv6 DUID regeneration

  • https://redmine.pfsense.org/issues/6667

    Instead of manually copying the file to /conf, you could install the cron package and back up the duid file every hour.  Because the file shouldn't change once created, and performing all kinds of extra writes to a CF or SSD is A Bad Thing, I use "-n" (no clobber) to make the backup.

    I have the following cron job:

    *  */1  *  *  *  root  /bin/cp -n /var/db/dhcp6c_duid /conf/dhcp6c_duid

    …and the shellcmd setting (copying from /conf/ instead of from /conf/dhcp/) above.

    (This should be improved to use "cp -f" if the timestamp of the copy in /var is newer than the backup.  In most linux distros, the "-u" parameter to cp would take care of that, but I don't see an equivalent in freebsd cp.)

    The whole idea is that a user could still manually delete the duid file if they needed to "fix" a broken duid (or get a new lease or something.)  If that happens, you'd want a new backup taken.  If DUID changes, update the backup.  Else, don't write to it.

    Of course, it'd be better still if backing up the duid file was incorporated into the scripts that backup (and restore) the dhcp leases automatically.

Log in to reply