IPV6 Renew WAN interface
-
Bit late in catching this conversation.
There are two issues here, one is the DUID not being remembered if you are using RAM temp folders, as the var folder is lost on reboot, and that's where the DUID file is. The solution is to save the DUID somewhere on the HD/SSD and use an early shell command to copy it back to var. I save my DUID in conf then use 'cp -f /conf/dhcp6c_duid /var/db/' as the early shell command, that fixes one issue.
The second issue is the dhcp6c client that sends a release signal to the server on exit, the server does as its told and gives you another address on next request. The solution to this is the same as was done to the Merlin - Asus firmware and to add a no release option to the client. I have modified the dhcp6c client plus the configuration and script changes required to handle the option.
I and a few others are running this successfully.
I cannot post a patch for this as it's a requirement that the FreeBSD dhcp6c client be updated as well otherwise the client will exit with error if the option is set on the existing client.
If anyone wants the files and instructions on how to install them, pm me and I'll send the relevant files. Note, I am running the latest 2.3.3 snapshots and this will not work on the stable releases.
-
FWIW, my prefix has changed on occasion, for nothing more than briefly disconnecting the cable modem from the pfSense computer. On the other hand it has survived rebooting the firewall and even replacing the cable modem. The DUID was created back in May and hasn't changed since. My ISP is aware of the issue and is looking into the cause of the problem.
-
Does not surprise me, the ISP's or at least some of them are often the cause of the problem as their V6 implementation is a little lacking. In our case we are 99.9% sure it was a router issue as it would only happen on a soft reboot, on a hard reboot it never happened.
-
Take a look at your DUID and check the creation date. You can capture it with the packet capture function in fpSense by filtering on port 546. You'll then have to find the relevant packet that contains it.
-
Take a look at your DUID and check the creation date. You can capture it with the packet capture function in fpSense by filtering on port 546. You'll then have to find the relevant packet that contains it.
Yes, I know all about the DUID, mine was created back in August. If you read my original message you'll I said there were two issues that can cause problems, one the DUID with RAM drive, and second the release of the allocation by dhcp6c.
-
There may be something in that. I have packet captures from both when the prefix changed and when it didn't. On the one that didn't change, the capture starts with a couple of renew XID lines, then some release XID etc. The one that changed goes right to several release XID lines and no renew XID at all.
Perhaps this is a bug with pfSense, but I don't know enough to say for certain.
Also, the capture that has the change was made with Wireshark on a different computer and the one that didn't change was captured by pfSense. However, I wouldn't expect that to make a difference. I used the separate computer as I found pfSense wasn't capturing the ones that changed, perhaps because I was disconnecting the cable modem, causing the interface to drop.
I'm running pfSense 2.3.2-RELEASE-p1 (amd64).
If someone wants to examine them, I could post the captures as attachments or send them via email.
-
It's not intrinsically a bug with pfSense, more a feature of ISP's using dynamic allocations.
When the wide-dhcp6c client was originally written and even to the current FreeBSD version it seems no-one thought of the issue of PD delegations being dynamic and changing, not all ISP's do it like this, but a few do, mine being one of them!
When dhcp6c is shut down by pfSense, remember that dhcp6c is part of FreeBSD ( all be it with some minor changes ) then as part of its shutdown dhcp6c will send a release signal.
What I have done, is to prevent that release signal from ever being sent.
-
What I have done, is to prevent that release signal from ever being sent.
How did you do that?
-
What I have done, is to prevent that release signal from ever being sent.
How did you do that?
I modified the client to add an extra parameter in the command line, then I modified interfaces.php to create the option to turn the 'no release' option on or off and modified the interfaces.inc to handle the option.
Job done.
-
Perhaps you can list the details. Also, as I mentioned earlier, the captures show a renew was not issued when the prefix changed. When a renew was sent the prefix didn't change. In either situation releases were sent.
-
Perhaps you can list the details. Also, as I mentioned earlier, the captures show a renew was not issued when the prefix changed. When a renew was sent the prefix didn't change. In either situation releases were sent.
And as I said earlier, this appears to be ISP specific, some do - some don't, and some do sometimes. It's a belt and braces job, remove all the possibilities and then see what you are left with. In our case it has solved the issue. A similar issue occurred with the DHCP6 and sending a solicit before RA, it only affects certain ISP's.
-
A network architect at my ISP is already looking into this. However, I'm still curious as to why pfSense did not send a renew on the occasion when the prefix changed. This is something that's beyond the control of the ISP.
When dhcp6c is shut down by pfSense, remember that dhcp6c is part of FreeBSD ( all be it with some minor changes ) then as part of its shutdown dhcp6c will send a release signal.
In my testing, psSense dhcp6c is not being shut down. I just unplug the Ethernet cable from the WAN interface. This should be seen as a failure to be recovered from rather than a deliberate shut down. Again, I see a release in both instances, but no renew when the prefix changes.
-
A network architect at my ISP is already looking into this. However, I'm still curious as to why pfSense did not send a renew on the occasion when the prefix changed. This is something that's beyond the control of the ISP.
In that particular case the BNG of your provider is seeing a lost connection and is arbitrarily giving you a new allocation, and yes your ISP should look into it.
When dhcp6c is shut down by pfSense, remember that dhcp6c is part of FreeBSD ( all be it with some minor changes ) then as part of its shutdown dhcp6c will send a release signal.
In my testing, psSense dhcp6c is not being shut down. I just unplug the Ethernet cable from the WAN interface. This should be seen as a failure to be recovered from rather than a deliberate shut down. Again, I see a release in both instances, but no renew when the prefix changes.
So you are seeing a release, this is what I am stopping with my changes, in our case the BNG does the correct thing and releases the allocation. DHCP6C cannot send a renew as it has released the allocation, along with timeout and the other putty it needs, It should now go back to square one and start the procedure for a new addess, if your ISP had no issues then you should get the same address again.
-
So why the difference with sending a renew on some occasions and not on others, when in both cases I just pulled the cable?
If you want, I can send you a PM to provide links to the captures, on Google Drive. Then you'll be able to compare the 2 situations.
-
So why the difference with sending a renew on some occasions and not on others, when in both cases I just pulled the cable?
If you want, I can send you a PM to provide links to the captures, on Google Drive. Then you'll be able to compare the 2 situations.
I'm not talking about renew I'm talking about release, two different things.
