DHCPv6 + SLAAC SG1000
I recently bought an SG1000 device for use on a corporate network.
I have had quite a bit of experience with pfSense before and am having trouble getting DHCPv6 and SLAAC to work on the SG1000.
As standard, when setting up DHCPv6+RA on a LAN you can input the DHCPv6 ranges and set the RA flags to assisted to get local devices to be allocated IPv6 addresses within a routed subnet. However, on the SG1000, no local LAN devices are being given any IPv6 addresses.
The LAN address on the SG1000 has an IPv6 address set to
[routed_subnet]::1/64. The DHCPv6 and router advertisements then simply work off that /64 subnet. However, on closer examination of the log files the DHCPv4 server seems to work absolutely fine, but there is never any queries or entries for the DHCPv6 server. It is consistently stuck in a listening state. Have mirrored the exact setup with other pfSense devices and the problems do not occur.
Is there any nuances that need to be addressed in the SG1000? Would appreciate it if someone could try to reproduce this issue.
P.S. I have attached the DHCP log file for your perusal. My public IPv6 range has been replaced for the string "ROUTED_IPv6_BLOCK".
Updated by James Webb about 4 years ago
On further inspection after clearing the log file and force restarting radvd, the routing log file simply consists of the following message:
Nov 10 19:59:44 radvd 60895 version 1.9.1 started
However, on the status->services page radvd is clearly not running.
After looking at system.log I see that the following entries are present:
Nov 10 20:13:06 UNKNOWN 42182 Process 87789 died: No such process; trying to remove PID file. (/var/run/radvd.pid)
Nov 10 20:13:08 kernel pid 42182 (radvd), uid 0: exited on signal 10 (core dumped)
Nov 10 20:13:27 UNKNOWN 50930 Process 42182 died: No such process; trying to remove PID file. (/var/run/radvd.pid)
Nov 10 20:13:29 kernel pid 50930 (radvd), uid 0: exited on signal 10 (core dumped)
These entries both occur after restarting radvd twice manually.
After seeing this I believe this is now a duplicate of #8022.