Comcast IPv6 working on Linux clients, but not Windows clients
-
@chpalmer Thanks. I once had an MB8600, and SB8200. I don't remember what IP they used. kept getting major but intermittent problems on my cable line - lots of packet loss and disconnects. Comcast always blamed my modem for the probblems, and wouldn't fix it. They claim they couldn't monitor the line. It went on for many months, and I just couldn't get them to do anything. One day I gave up, sold my modems, and leased their gateway. Finally, they did fix it. My home is at the very end of the cable line on top of a hill. It is frequently affected by whatever Comcast does on their network. Comcast claims they cannot remotely monitor error statistics from 3rd party modems, but they can do so for their own modems/gateways. They also keep installing non-UV resistant cable on the front of my home in the hot California sun, which they have replaced at least 3 times in the last 15 years. SMH.
The other reason why I have the XB8 is for the unlimited data plan. I believe they charge an extra $30/month for unlimited data if you use a third party modem. That is a pretty big extra expense, on top of the purchase cost of the modem itself. But the overwhelming reason I keep their gateway is because I don't want them to be able to blame my equipment again for their line problems, which are likely to happen again.
-
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
A /128 might work if you have a single client device connected, but not for multiple devices.
No. You'd still need 2 addresses. The /128 can only be reached by routing through pfSense. As I mentioned, it's only for identifying the interface. It would be used for things like pinging the interface, connecting a VPN, etc..
-
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
top of a hill
Yeah, it's hard to get the bits up that hill!
-
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
However, the fact that you only have a single device connected to pfSense may mean that it isn't a fully working configuration
'behind pfSense' : I said Comcast IPv6 working on Linux clients, but not Windows clients:
As my pfSense is the only device connected to my ISP route
So my ISP 'fiber' router has only one (1) LAN client device : pfSEnse.
pfSense has loads of devices connected over using 3 LANs.@JKnott said in Comcast IPv6 working on Linux clients, but not Windows clients:
The /128 address is used only to provide an address for the interface. It is not used for traffic passing through pfSense. There's a /64 unique local address for that.
The fe80.... I guess. Thanks for the info.
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
I have many "Address leases" under that screen. But nothing under "Prefix delegation leases".
pfSense would lease out 'entire' prefixes if you have a DHCPv6 capable router on a pfSense LAN.
This router would have a IPv6 address on it's WAN side.
And would typically ask for an /64 prefix for every LAN it has. Exactly like pfSense does.
The pfSense DHCPv6 would not only handle IPv6 leases, out of one prefix pool :
It also has to be set up to have a 'pool' of available prefixes, so it can give these /64 to any downstream 'sub routers' :
pfSense handling the delegation of prefixes is ... afaik, a very rare situation.
Are you sure you want to "Prefix delegation leases" with pfSense ?@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
After rebooting all network equipment, a couple of Windows systems did have working IPv6 initially, about 5 minutes after booting up. Then, subsequently, IPv6 stopped working for them, as reported in my OP.
No need to keep the 'not working' state.
Ask your system why ?!
Typeipconfig /alland you can see for yourself :
IPv6 Adress. . . . . . . . . . . . . .: 2a01:cb19:907:a6e2::c7(prefered)How long does the DHCPv6 last ?
Answer :netsh interface ipv6 show addressesFor example :
Dhcp Prefered 5h14m22s 2h25m37s 2a01:cbxx:xx7:a6e2::c7so my lease stays valid for 314 minutes and 22 seconds. If all goes well, it (Windows) will renew this lease before this lease expires **.
On the pfSense side, the same lease :
Take note : I'm only using DCPv6 for my network LAN network, as all these devices are 'known' to me, these are mostly all IPv6 capable devices. All devices have a 'static DUID DHCPv6' setup.
**
Something that annoys me for, not sure, months now, maybe a bit more then a year (since kea ?) :
It happens that Windows devices do not, for some reason, renew their IPv6 lease in time. The IPv6 becomes "depreciated" as the lease time expires.
Why the dhcpv6 client daemon doesn't renew in time, I can't tell.
A quickipconfig /renew6on that Microsoft device will deal with it, but still, this is awkward.
The lease times on the pfSense side :
or 2 hours if the client didn't specify a lease duration.
and 24 hours or 1440 minutes maximum.When I :
ipconfig /renew6right now, I see :
Dhcp Prefered 7h29m56s 4h41m11s 2a01:cbxx:xx7:a6e2::c7or 7h30 or 450 minutes or 27000 seconds.
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
If none of this works consistently, it looks like I need to reach out to Comcast.
Who handles the DHCPv6 in front of pfSense ?
The ISP box at your place ?
Further above ?
Do you see this in the pfSense DHCP log :
which tells me the DHCPv6 pfSense WAN IP has a lease time of 10 minutes.
The pfSense DHCPv6 WAN client renews every 300 seconds or 5 minutes.
Afaik, the prefixes are also renewed at that time. And hopefully, they 'stay the same' ^^ - mine always stay the same, as I can see them allocated to pfSense in my ISP router. -
Thank you very much for this. I had not checked the "Primary address pool" section. This is what it shows.
The UI is slightly different, possibly because I'm on pfSense+. But I believe the settings are the same.
I'm typing this on a Windows machine on which IPv6 is currently working. Your netsh command shows this :
Interface 12: Ethernet 4 Addr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Dhcp Preferred 1h26m7s 41m7s 2601:646:8200:xxxx::xxxx Temporary Preferred 23h56m33s 3h56m33s 2601:646:8200:xxxx:xxxx:xxxx:xxxx Public Preferred 23h56m33s 3h56m33s 2601:646:8200:xxxx:xxxx:xxxx:xxxx:xxxx Other Preferred infinite infinite fe80::xxxx:xxxx:xxxx:xx%xxI don't have any static mapping for DHCPv6 clients. How did you add them ?
It seems like a ton of work to manually undter a DUID and IPv6 address for each of my devices. I wouldn't know the right value to enter. I'm not even certain how many of the 350 support IPv6 or not. Can this really not be made to work automatically ?Simultaneously, on another Windows host on the same LAN, test-ipv6 is not working. The netsh command on that box shows :
Interface 18: Ethernet 3 Addr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Dhcp Preferred 1h30m55s 45m55s 2601:646:8200:xxxx::xxxx Public Preferred 23h53m23s 3h53m23s 2601:646:8200:xxxx:xxxx:xxxx:xxxx:xxxx Temporary Preferred 23h53m23s 3h53m23s 2601:646:8200:xxxx:xxxx:xxxx:xxxx:xxxx Other Preferred infinite infinite fe80::xxxx:xxxx:xxxx:xxx%xxI'm not seeing a lot of difference in the format of those addresses between the 2 boxes. The non-working one has a longer "temporary" IPv6 address than the working one.
As far as I know, the interfaces are configured identically on both machines as far as protocol settings.
Working box :
Non-working box :
-
To answer the other questions - who handles the upstream DHCPv6 - I believe it's the ISP, outside my home, not the box itself.
I'm still using ISC - not KEA. I tried to switch to KEA last year, and lots of things broke, especially Plex.
I tried earlier today also, and pfSense very weirdly went to a non-booting state. My COMCAST interface got renamed to WAN. Another NIC that I used for another ISP in the past started showing up as enabled again in the boot messages. I was able to restore a backup. I'm not sure why KEA would mess up so bad.
I'm not seeing any messages from dhcp6c except this:
Nov 5 18:19:03 rtsold 57093 RTSOLD Lock in place - sending SIGHUP to dhcp6c
-
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
I don't have any static mapping for DHCPv6 clients. How did you add them ?
DHCPv4 : you know how it works : get the MAC of the device, and create a "static MAC" entry :
and done.
This device will from now on always have the same IPv4 LAN my LAN network : 192.168.1.6.
As I don't add/remove/change a lot of hardware, maybe one or two devices a year, this is easy to maintain. It also gives me a list of all known devices in my network.
So, if a device connects to my (company) LAN that uses a lease out of the DHCPv4 'pool' I know I have a new device - and that is a security question (for me). Shall I accept it, and give it its own reserved static IPv4, or is it just some occasional device ?
I do have another network, a captive portal, for all the devices that are visiting my company, a hotel.Now, for DHCPv6 : it's all the same, with one exception : MACs can't be sued anymore, as devices can have more then one IPv6.
So the DUID was invented.
As shown above, I use the DUID of every device to create static DHCPv6 leases for all my trusted LAN devices.
If a IPv6 pops up that came from the pool - for me between :
then I have the same decision to make : a new device entered my LAN network : shall I add it for good, or was it just a temporary connection ?
When I look at my Status > DHCPv6 Leases page, I can see right away that there are no unknown devices, using IPv6, in my network. (the same is valid for Status > DHCP Leases ).
Remember : devices on your LAN won't be protected by pfSense.Making static leases for known LAN devices also gives you a nice list of all your equipment on one place. No need to deal with 'IP' on any devices anymore. Leave them all on the default 'DHCP' mode, and done.
Another advantage : I can chose the host name of all my device on one place.edit :
I've switched to kea last year, and never came back. Some 'minor' issues existed back then, but nothing mission critical that broke.
These days, with "25.07.1", is good enough for me.be ware that I can't compare kea with ISC.
You might also be dealing with old ISC IPV6 bugs (that won't get fixed anymore).
I deal with the new bugs - that are discussed here on the forum - and will get fixed ;)
That said, IPv6, when I was using ISC, was working well enough for me. With kea it also works well (now). -
@Gertjan I already have DHCPv4 reservations for all 350 IP devices I own, along with custom hostnames. The pace of adding and removing devices in my home is much more rapid - usually a couple each month.
For DHCPv6, I see only a grand total of 16 leases. It just can't be that only 16 out of the 350 support IPv6. It is difficult to identify which DUID corresponds to which piece of hardware. It looks like the MAC is embedded into the DUID. The DUID is variable-length, though. I found the entry for my currently working desktop PC. It has the MAC of the Aquantia NIC as the last 12 hex digits of the DUID. The IPv6 address shown corresponds to the 'IPv6 address" from ipconfig on that system.
For the other non-working Windows system, I can't find any corresponding entry under leases.
I'm going to take a look at the remainder of the DHCPv6 leases, since there are so few of them, and try to figure out what they are.
-
@Gertjan said in Comcast IPv6 working on Linux clients, but not Windows clients:
edit :
I've switched to kea last year, and never came back. Some 'minor' issues existed back then, but nothing mission critical that broke.
These days, with "25.07.1", is good enough for me.be ware that I can't compare kea with ISC.
You might also be dealing with old ISC IPV6 bugs (that won't get fixed anymore).
I deal with the new bugs - that are discussed here on the forum - and will get fixed ;)
That said, IPv6, when I was using ISC, was working well enough for me. With kea it also works well (now).Thanks. I just checked my version, and it says it's on 24.11 . It may be because of a backup I restored. I don't think restoring a backup would roll back the firmware, though. I could have sworn I had already upgraded to 25.07.1 .
I went to System / Update / System update just now, and tried to select the current stable version, 25.07.1 . But it says "Another instance of pfSense-upgrade is running. Please try again in a few moments".
That's probably because "Boot environment" is shown as "broken-20250127220801". Looks like there is another one called default_20251006131313 . I don't want to switch back to it, since it seems like it's proceeding to upgrade the current boot env. sigh.
Edit: that default_20251006131313 environment shows "Boot verification failed". I cannot switch to it. It goes back to 24.11 as a result. It complains during boot that the current configuration was created with a newer version, also.
It looks like my pfSense SSD may be seriously hosed. Good thing I have a hotswap SATA drive bay and a few spare SSDs. Time to figure out how to flash another one, sigh.
-
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
But it says "Another instance of pfSense-upgrade is running. Please try again in a few moments".
and if for some reason you (pfSense) have issues reaching the Netgate upgrade servers, it will stay in that mode forever. Thus locking you out for any updates (and pfSense package updates).
Short cut : as always : go to the place where you have power : console or SSH.
Option 8 and kill all 'pkg' processes.
Back up one level, and use option 13: update from console.You see issues know : you have a 99,99 % change that issue is already documented in the pfSense upgrade documentation or here ion the forum.
Better cut : export you config.xml.
Get the installer and burn it to a USB drive with etcher (see pfSense doc).
Install your device with the USB drive.
Import, if needed, the config.
Done.
Now you have a clean system, with all the latest stuff, latest ZFS layout and partitions, everything.@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
Time to figure out how to flash another one, sigh
That might be valid for the big desktop OSes or servers with loads of data, programs etc.
Not valid for pfSense : there is one (1 !) config file to keep.
Re installing is waaaay faster. -
@Gertjan said
Time to figure out how to flash another one, sigh
That might be valid for the big desktop OSes or servers with loads of data, programs etc.
Not valid for pfSense : there is one (1 !) config file to keep.
Re installing is waaaay faster.Thanks. I have nightly backups of my config.xml . I agree reinstalling is much faster.
I meant that I needed to figure out how to flash the USB stick for the reinstall. Which I'm doing now. But Etcher just failed after the verification, sigh.
-
-
@Gertjan Thanks. I was able to recover the system. Etcher somehow reported an error, but the media was good. I tried 2 different media.
pfSense is up and running again, this time with 25.07.1 .The problem of IPv6 inconsistency is still there. I took a look at the DHCPv6 leases again, and found something very interesting :
Two different leases have a very similar DUID - one that ends with the 12 hex digits of the MAC of one Windows machine, the currently working one. That is extremely strange. They are using different brand NICs, too.
-
Suspecting an issue with ISC DHCP server, I tried to switch to KEA through System / Advanced / Networking .
This immediately resulted in an unbootable system, without any recovery option offered. Admin UI not accessible from LAN. Only able to login locally thanks to the system being on a KVM switch.
KEA looks like it really shat the bed. Maybe it can't handle the 350 IPv4 DHCP reservations. It's a really awful state for the system to be in.
Fortunately, I was able to recover the previous working config by copying it manually with cp /cf/conf/backup/config-XXX.xml to /cp/conf/config.xml .
Still not sure what it would take to get KEA actually working, sigh.
Edit: I tried deleting all the staticmap entries. Still no go. My system just won't boot with KEA.
-
That's no kea doing anything wrong.
And it's not a IPv6 issue, but an IPv4 issue.
It might be a left over from a GUI issue that wrote something 'not allowed' to the config.
After the admin entered info (of course) that was plain wrong - and not flagged by the GUI.
tells the story.
What I see :
During the boot process - because initiated during /etc/rc.bootup stage
The /etc/hosts file is created (even windows has one, every system has this file - go have a look and you know what it is, why it is so universally known) - and this is where kea_earlydnsreg_mappings is called, as, imho, this is the place where static DHCPv4 leases are copied to the host file, as these never change, and can be seen as static host file entries.
My take : one of your DHCPv4 static leases entries - go have a look at the config file, you'll find the one that has an "illegal" format ....
I suspect that one of your :<dhcpd> <lan> ..... <staticmap> // one of these has an error .......has some info that is wrong.
and this is the reason /etc/utils/inc at line 3999 fails ...
and because the fail happens during system wide init (boot), pfSense breaks the boot process.
Quick and dirty solution : edit the config.xml with a good editor - not msword, use notepad++
Ditch all the
.....
<staticmap>
</staticmap>
.......
save, put the file in place, and done.You'll loose your DHCP4 static entries, but these can be put in place the same way you've removed them, when you've found the entry that contains the syntax error.
it's xml, the format is pretty straight forward. -
@Gertjan
As I said in my last message, I tried deleting all the <staticmap> entries from the <dhcpd> section. And KEA DHCP still would not boot.What I did to finally get it working.
- use admin GUI to disable LAN interface
- reboot to console
- change <dhcpdbackend> from isc to kea
- from console, manually reset IP subnet on LAN, to re-enable DHCP
- at that point, pfSense booted successfully with KEA
- I then downloaded the DHCP server section, and pasted back all the <staticmap> entries exactly as they were before
- KEA DHCP still worked fine, even after reboot
- I also had to manually enable KEA on LAN for DHCPv6, and re-enable RA / stateless mode
My guess is that it had to be something else in the <dhcpd> or <dhcpdv6> sections from the ISC config that KEA did not like - but it was not the <staticmap> entries.
At this point, my system is working again, with KEA. All my devices have their expected IPv4 addresses, from existing reservations.
test-ipv6 is still working fine on all the Unix hosts I checked.
But it is not working on any of the Windows hosts as I type this.The one improvement I see is that the "DHCPv6 leases" screen now shows names in the "Hostname" column, which was previously empty when using ISC.
"Flash" and "Higgs" are both Windows PCs. Flash has an Intel X550-T2 NIC (only one port in use). Higgs has an Aquantia AQN-107 NIC.
The DUID for both systems contains the 12 hex digits of the Aquantia NIC from "Higgs". I'm only showing the last 6 here.
An extremely large number of devices is missing from the DHCPv6 list. I have 7 WiiM Pro Plus, 2 Narwal robots, 2 Raspberry Pi controlling my dual HVAC systems, etc.
Anyway, it is 3am now, and I'm going to leave the network in this state for now.
-
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
But it is not working on any of the Windows hosts as I type this
On these windows devices,
ipconfig /renew6doesn't do it's job ?
IPv6 is disabled on these devices ?When I packet capture DHCPv6 requests, I can see the DHCPv6 request (from the windows device) and proposal (from pfSense).
-
@Gertjan ipconfig /renew6 gives the Windows hosts IPv6 addresses that look fine. The problem is that they are not usable. Ping fails with "General failure" with any IPv6 address I try.
>ping 2001:4860:4860::8888 Pinging 2001:4860:4860::8888 with 32 bytes of data: PING: transmit failed. General failure.There is likely some kind of routing issue. But it only affects the Windows hosts - and only temporarily. On a Linux host, it always works :
madbrain@office-pi4:~ $ ping 2001:4860:4860::8888 PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=116 time=18.4 ms -
Two different leases have a very similar DUID - one that ends with the 12 hex digits of the MAC of one Windows machine, the currently working one. That is extremely strange. They are using different brand NICs, too.
I figured this one out. The Aquantia NIC had been moved between those two systems. Windows generated the DUID based on the MAC of that NIC, and stored it in the registry. I tried deleting it from both systems. Windows regenerated a new DUID that still contained the same MAC. The DUID generation algorithm must be relying on another store to find that MAC. I can't be bothered to try to fix it. Now that the hostnames are showing in the DHCPv6 leases with KEA, I am able to identify the hosts for each lease, without needing to check the MAC embedded in the DUID. The DUIDs are still unique, so it is not causing actual issues, just confusion.
-
@Gertjan So, clearly, the problem is the default route for ::/0 .
Windows clients should be getting this route from the RA. But somehow, they are not.I spent a lot of time with chatgpt trying to figure this out, changing a variety of settings on the pfSense and Windows sides, including packet captures for ICMPv6 - to no avail.
The only solution that was ultimately found was to add the route manually, with a PowerShell script like this :
PS C:\> type .\addroute.ps1 # SCRIPT TO FIX PF SENSE ROUTING ISSUE PERMANENTLY # Run this script as Administrator whenever IPv6 connectivity is lost. # 1. Configuration Variables # Interface Alias is "Ethernet" based on Get-NetAdapter output. $TargetInterface = "Ethernet" # This is the stable Link-Local address of your pfSense LAN interface. $PfSenseLinkLocal = "fe80::a236:9fff:fefa:8a31" $Destination = "::/0" # 2. Remove Existing Route (Ensures we don't duplicate or conflict) Write-Host "Attempting to remove old default route to $PfSenseLinkLocal..." Remove-NetRoute -InterfaceAlias $TargetInterface -DestinationPrefix $Destination -NextHop $PfSenseLinkLocal -Confirm:$false -ErrorAction SilentlyContinue # 3. Add New Persistent Route Write-Host "Adding new persistent static route via PowerShell..." # New-NetRoute is persistent by default when used in this manner. New-NetRoute -InterfaceAlias $TargetInterface -DestinationPrefix $Destination -NextHop $PfSenseLinkLocal -RouteMetric 10 Write-Host "SUCCESS: IPv6 default route is now active and persistent."For good measure, here is the deletion script.
PS C:\> type .\delroute.ps1 # SCRIPT TO DELETE THE PERSISTENT STATIC IPV6 DEFAULT ROUTE # 1. Configuration Variables $TargetInterface = "Ethernet" $PfSenseLinkLocal = "fe80::a236:9fff:fefa:8a31" $Destination = "::/0" # 2. Remove the Existing Route Write-Host "Attempting to delete the persistent static default route..." Remove-NetRoute -InterfaceAlias $TargetInterface -DestinationPrefix $Destination -NextHop $PfSenseLinkLocal -Confirm:$false -ErrorAction SilentlyContinue # 3. Verification Write-Host "Route deletion process complete. Checking routing table..." Get-NetRoute -InterfaceAlias $TargetInterface -DestinationPrefix $Destination -ErrorAction SilentlyContinue if ($LASTEXITCODE -ne 0) { Write-Host "SUCCESS: Route ::/0 pointing to pfSense has been successfully removed." } else { Write-Host "WARNING: Route may still be present. Please check manually."Test :
PS C:\> ping 2001:4860:4860::8888 Pinging 2001:4860:4860::8888 with 32 bytes of data: PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. Ping statistics for 2001:4860:4860::8888: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), PS C:\> .\addroute.ps1 Attempting to remove old default route to fe80::a236:9fff:fefa:8a31... Adding new persistent static route via PowerShell... ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore ------- ----------------- ------- ----------- -------- ----------- 8 ::/0 fe80::a236:9fff:fefa:8a31 10 15 ActiveStore 8 ::/0 fe80::a236:9fff:fefa:8a31 10 Persiste... SUCCESS: IPv6 default route is now active and persistent. PS C:\> ping 2001:4860:4860::8888 Pinging 2001:4860:4860::8888 with 32 bytes of data: Request timed out. Reply from 2001:4860:4860::8888: time=14ms Reply from 2001:4860:4860::8888: time=10ms Reply from 2001:4860:4860::8888: time=8ms Ping statistics for 2001:4860:4860::8888: Packets: Sent = 4, Received = 3, Lost = 1 (25% loss), Approximate round trip times in milli-seconds: Minimum = 8ms, Maximum = 14ms, Average = 10ms PS C:\> .\delroute.ps1 Attempting to delete the persistent static default route... Route deletion process complete. Checking routing table... WARNING: Route may still be present. Please check manually. PS C:\> ping 2001:4860:4860::8888 Pinging 2001:4860:4860::8888 with 32 bytes of data: PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. Ping statistics for 2001:4860:4860::8888: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), PS C:\>This works, but is very brittle, since the scripts hardcode the name of the LAN interface as "Ethernet". It will be different on every Windows system or VM. If I install Hyper-V on my host, the interface name changes also. Maybe the script can be made smarter. But the point is that it really shouldn't be necessary to set the route manually. Something is just not right with the way pfSense interacts with Windows IPv6 clients.
I'm inclined to think that this is a pfSense configuration issue, since these Windows clients all work fine with IPv6 when I use the Comcast XB8 as router instead of pfSense.
I'm at a loss as to what to do to fix the routing in the pfSense config, though.
