Comcast IPv6 working on Linux clients, but not Windows clients
-
@Gertjan I set up a brand new Windows 11 Enterprise VM earlier today just to test, with its own MAC, bridged. It did not work. IPv6 routing still broken.
Buying a new PC will not help. -
@Gertjan and yes I know very well that the /24 is for IPv4. I'm just reporting what I observed - when I reverted to the old configuration with /24 on IPv4, and fewer than 100 clients connected, the IPv6 routing on the Windows hosts got fixed. It doesn't make any sense why that would be, but there you have it.
Whereas when I use the /22 on IPv4, and all 350 clients are connected, the IPv6 routing breaks on the Windows hosts.
As I said, makes no sense which is why I'm thinking there is a bug somewhere, either in pfSense or Windows.
-
@Gertjan And I do not use VLANs either. All my switches are unmanaged.
While experimenting today with various configuration, I ran into massive problems with IPv4 too. Sometimes the hosts wouldn't get IPv4 at all, only IPv6. This was across all hosts, though, not just Windows hosts
At present, another oddity is that when I ping the same public IPv4 host, say 1.1.1.1 or 8.8.8.8, from 2 Windows machines on my LAN at once, only the first machine gets the ICMP packets back. Second box only gets ttimeouts. If I ctrl-c on the first box, the second box starts getting ICMP replies back. This may be a separate problem from the IPv6 issue, but is sure is extremely puzzling.
No issue if 2 LAN hosts simultaneously ping the same public host.
-
@Gertjan As to why I went to a /22 earlier this year, it is for smart lighting. I replaced about 220 LED bulbs with Wi-Fi bulbs. They are powered at all times in order to be controllable remotely by Wi-Fi. The 97 switches on the wall are Z-wave. They are used as scene controllers only- the relay is always on.
I could temporarily turn off the relay on enough z-wave switches to bring the total number of IP devices down. For example, my home theater has almost 40 light bulbs on just 3 switches, so that would be a quick reduction. With a few more switches/ rooms turned off, I could bring down the device count below 255.
I can of course also turn off the WiFi SSID, which will remove about 300 devices at once, but then I won't have any way to turn lights on or off. -
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
I set up a brand new Windows 11 Enterprise VM earlier today just to test, with its own MAC, bridged. It did not work. IPv6 routing still broken.
Buying a new PC will not help.Ok, then the IPv6 problem is on the pfSense side.
@madbrain said in Comcast IPv6 working on Linux clients, but not Windows clients:
As to why I went to a /22 earlier this year
Yeah, but again, imho, IPv4 works.
Your issue is IPv6 related. -
Yes, the problem with IPv6 is definitely on the pfSense side.
My entire network - all 350 devices - works perfectly fine if I remove pfSense and set the XB8 to router mode, with a 10.0.0.1/16 . No IPv4 or IPv6 issues anywhere, including Windows systems.
But the XB8 is very limited as router - no local DNS, cannot handle 350 DHCP reservations, no Wireguard inbound VPN. These are the reasons I'm using pfSense. IPv6 not working is a problem, though.
-
@Gertjan said :
Yeah, but again, imho, IPv4 works.
Not fully. The IPv4 ping issue I ran into is still there, even with a very basic network with pfSense using factory defaults. I suspect a NAT problem. Again, this problem does not exist when using the Comcast XB8 as router, bypassing pfSense.
I filed a report in the NAT forum :
https://forum.netgate.com/topic/199273/2-windows-hosts-cannot-receive-echo-ping-from-the-same-ipv4-internet-host-simultaneously
That issue might not be related to the IPv6 problem I have been running into in this thread, though.
-
@Gertjan said in Comcast IPv6 working on Linux clients, but not Windows clients:
.
So, I have been pulling my hair today trying to figure out what triggers the issue, making so many config changes to pfSense, rebooting, and putting some devices offline temporarily.
I have not come to a conclusion as to the root cause, still, but I did isolate something that triggers the problem.
-
I went back to my original pfSense configuration, before I started this thread, with IPv6 not working on Windows clients. That config includes a 192.168.100.1/22 on the IPv4 side, as well as 350 DHCP reservations.
-
I disabled all SSIDs on my Ubiquiti Wifi APs (9 x U6-LR and 1 x NanoHD). Doing so had the effect of disconnecting about 300 Wifi clients from the LAN/WLAN.
-
I put 2 Windows systems to sleep, and woke them back up, to reset the network settings.
-
Immediately after waking them up, full IPv6 connectivity was restored on both Windows systems, including proper routing.
-
If I re-enable the Wifi SSIDs, and suspend & wake both Windows systems again, the IPv6 gets broken in both of them upon wakeup.
I'm still not really sure what could be causing this issue. One theory is that there is some kind of IPv6 maximum client limit is being hit. I am guessing this is the case, because I only see a maximum of 16 leases on the "DHCPv6 leases" screen, even with all 350 clients connected. While it is probably that not all 350 clients fully support IPv6, I would still expect there to be many more than 16 DHCPv6 leases.
The other theory would be that some client(s) are interfering with the RA packets, somehow, confusing the Windows boxes, and interferring their IPv6 routes. Not sure how likely that is. I have not taken the step of running Wireshark in promiscuous mode to find out.
-
-
@madbrain
Did you try just Unmanaged RA?
with disabled dhcpv6 server? All my devices including android and windows are working just fine. -
@w0w Thanks. I had no tried it yet. I just did. pfSense asked me to disable DHCPv6, which I did. I cleared all the DHCPv6 leases, also. Put my Windows clients to sleep, and woke them up. Unfortunately, same behavior - they get an IPv6 address, but routing is broken. Android & Linux clients are still fine.
Edit: turned off the Wifi IOT SSID again, and Windows clients are back to working in IPv6 mode, even with RA in Unmanaged mode.
I have been writing some scripts with the Unifi API to block specific clients based on MAC prefix. I'm down to 48 unblocked clients on the IOT SSID now. They are still causing IPv6 to break on the wired Windows clients ... Got a few brands of devices left to block. Hopefully it is a specific device causing the issue, and not a device limit I'm hitting.
-
So, it wasn't until I got down to 0 unblocked IOT clients that the problem resolved. Meaning, the problem wasn't caused by a specific client.
I went to check the IOT SSID setting in the Unifi controller. It had something called "Proxy ARP" enabled. I disabled it. Miraculously, all problems with IPv6 on the wired Windows hosts went away. This is really crazy.
