PFSense Not Working with DHCPV6 or Stateless on tracking interface
-
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?
-
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.
-
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.
-
yes I'm also running @marjohn56 patch on Sky in the UK and its so stable its becoming a little dull now LOL
And my logs are ALL SO QUIET
-
Comcast has now assigned me a static IPv6, which has "resolved" my issue, in theory
I still think unmanaged RA + Tracking interface should work.
What would be a good way to collect information on why its not working?
-
Comcast has now assigned me a static IPv6, which has "resolved" my issue, in theory
I still think unmanaged RA + Tracking interface should work.
What would be a good way to collect information on why its not working?
Tracking interface refers to the ISP. Unmanaged RA refers to your LAN. Try using assisted.
-
Tracking for v6 sets the IP to something based off the IP used on the tracked interface
2604:301a:936:eb00::xxxx when tracked goes to 2604:301a:936:ebe0::xxxx
I altered my IP, as to not expose it to the forum.
If I have tracking on, and enable RA, RA doesn't assign my windows boxes IPs.
If I take the same exact totally unaltered IP that tracking gives me, and make it static, RA works.That screams bug to me.
Assisted doesn't make a difference. I've also tried it. It works exactly like unmanaged for IP assignment, from what I can tell.
I just want to make sure this is bug before I report it to the bugtracker
-
All I can tell you is that I have no problems, and as RA is quite a major part of V6 on the LAN I would have assumed others would be screaming if it did not work for them.
-
Tracking for v6 sets the IP to something based off the IP used on the tracked interface
2604:301a:936:eb00::xxxx when tracked goes to 2604:301a:936:ebe0::xxxx
I altered my IP, as to not expose it to the forum.
If I have tracking on, and enable RA, RA doesn't assign my windows boxes IPs.
If I take the same exact totally unaltered IP that tracking gives me, and make it static, RA works.That screams bug to me.
Assisted doesn't make a difference. I've also tried it. It works exactly like unmanaged for IP assignment, from what I can tell.
I just want to make sure this is bug before I report it to the bugtracker
I will vouch for Martin that tracking is working just fine. pfSense takes the prefix assigned by the edge router, concatenates the 8 bit "IPv6 Prefix ID" (not a great name, IMO) and makes a /64 (i.e., prefix + ID/64). I imagine if the prefix was smaller than /56, pfsense would pad the bits between the prefix and the ID (i.e., prefix + padding + ID/64) to make up for the difference. All addresses allocated by SLAAC or dhcpv6 will use that prefix, but you have to set the range properly (e.g., ::1000 to ::2000 or whatever).
If you use assisted, you will get both SLAAC and dhcpv6 addresses. This is required if you have windows and android devices. Windows uses both, but android only supports SLAAC.
Note, if you are using windows 10, dhcpv6 got broken in the anniversary update and still hasn't been fixed.
If it's still not working, please post screen captures.
-
HI there. I am new to this, but I think I have the same error, so instead of openining a new thread, I post into this discussion, hope this fits and is ok.
pfsense 2.3.3 on a fritbox 6490.
I also complain that the tracked interface has a different IPV6 subnet than the interface that is tracking, but share the idea that it must be me, otherwise more people would complain :)
So I have my router (fritzbox) that receives an IPV6 xxxx:xxxx:a59f:8700::/56.
Behind it, I have pfsense with WAN, LAN and DMZ.WAN 1000baseT <full-duplex>192.168.178.22
xxxx:xxxx:a59f:8700:20c:29ff:fe84:d9cfLAN 1000baseT <full-duplex>DMZ 1000baseT <full-duplex>10.254.0.1
xxxx:xxxx:a59f:87ff:20c:29ff:fe08:ccaAs you can see, the DMZ does has 87FF, not 8700 like the WAN. That is bad as I think that makes it impossible for the devices in that DMZ to receive a 8700 address, which is needed for portforwarding. Fritzbox will not forward 87FF… if I change the prefix ID in the option tracked interface, it gives me more options, but I cannot get it to become 00.
my wan setting is set to DHCP6/64 with that hint-checkbox.
my dmz setting is set to track interfacfe WAN prefix ID: 0.PS: Oh and I tried DHCP relay to the WAN-Gateway (FE80::.. Fritzbox) which didn't work either. ANd cannot use static as I've been told it willchange often.</full-duplex></full-duplex></full-duplex>
-
HI there. I am new to this, but I think I have the same error, so instead of openining a new thread, I post into this discussion, hope this fits and is ok.
pfsense 2.3.3 on a fritbox 6490.
I also complain that the tracked interface has a different IPV6 subnet than the interface that is tracking, but share the idea that it must be me, otherwise more people would complain :)
So I have my router (fritzbox) that receives an IPV6 xxxx:xxxx:a59f:8700::/56.
Behind it, I have pfsense with WAN, LAN and DMZ.WAN 1000baseT <full-duplex>192.168.178.22
xxxx:xxxx:a59f:8700:20c:29ff:fe84:d9cfLAN 1000baseT <full-duplex>DMZ 1000baseT <full-duplex>10.254.0.1
xxxx:xxxx:a59f:87ff:20c:29ff:fe08:ccaAs you can see, the DMZ does has 87FF, not 8700 like the WAN. That is bad as I think that makes it impossible for the devices in that DMZ to receive a 8700 address, which is needed for portforwarding. Fritzbox will not forward 87FF… if I change the prefix ID in the option tracked interface, it gives me more options, but I cannot get it to become 00.
my wan setting is set to DHCP6/64 with that hint-checkbox.
my dmz setting is set to track interfacfe WAN prefix ID: 0.PS: Oh and I tried DHCP relay to the WAN-Gateway (FE80::.. Fritzbox) which didn't work either. ANd cannot use static as I've been told it willchange often.</full-duplex></full-duplex></full-duplex>
A picture of your connectivity would be helpful. If you're connecting a pfsense to another router, the port should either be bridged through to the ISP edge router or the router pfsense is connected to must be able to delegate a prefix.
Please provide screen captures of your LAN, WAN and dhcpv6 settings.
