@Bob-Dig ah I thought that setting it enabled meant all incoming IPV6 WAN traffic would be allowed in. If I'm enable is default WAN inbound still block for IPv6?

Here is update: I requested an IPv6 prefix from the second ISP, who was able to split it and set up routing to the related WAN IP addresses. I then contacted the first ISP again and they agreed to do the same. Problem solved, I can still run the routers independently. ☺

@patient0 Haha, yeah, but look how bad my IPv6 is!
Going to leave it with IPv4 preferred, but thank you very much for taking the time to help. Those were great suggestions, and in the end this issue just highlighted how bad my ISP's IPv6 is.
Hyperoptic, get your IPv6 house in order!

@F022Y said in Lit Fibre (UK) IPv6 stopped after powercut:

First step was to check the internet was actually down

Note these on an post-it :

ipconfig /all ipconfig /renew ipconfig /renew6

The second renews the IPv4 lease. If it times out : DHCP4 isn't running ?
The third : IPv6 lease gets renewed. If error, DHCOPv6 server isn't running ? (or no more prefix for that LAN, etc)

Be ware : IPv6 is default, so if "ping www.google.com" will use IPv6. Force it to use IPv4 by entering :

ping -4 www.google.com

or the other way around :

ping -6 www.google.com

@F022Y said in Lit Fibre (UK) IPv6 stopped after powercut:

only IPv6 traffic worked and IPv4 was a no go

Welcome into 2025, Yes, DHCP4v should be stable right these days.
If any doubts, use the DHCPv4 server (on pfSense) that is known to be good : use ISC. You are using kea right now.

34ba9510-17e6-4205-8b77-3379a1a610e3-image.png

kea works fine, I'm using it for month now, but I have the more recent 24.11 (and 25.03 now).
IMHO : If you have to offer your wife a depreciated (but 3 decades proven) DHCPv4 server, or a 'beta' (implementation) Kea, go for the first - or get a lawyer ^^

@Bob-Dig

That's very Interesting, oddly though, the client with 0 issues is also the client with the extra stale ipv6 addresses.

I found some info on some MS forms that suggests Windows has an issue when the NIC is using both IPV4 DHCP and IPV6 RA at the same time. i.e. other have seen similar DNS weirdness. On the broken system I just tried disabling IVP4 TCP/IP and after rebooting that same box now receives an IPV6 DNS Server. If I then re-enable TCP/IPV4 on the nic, that same system wipes out the DNS servers and replaces with only an IPV4 value.

So this is really starting to feel like a pure MS bug, I don't see how the above could be influenced by PFSense.

Deleting this thread and starting over, fixed my issue but found a new one.

@timg_11 The images are available on the Wayback machine at archive.org.
I just did the same thing as you, but I'm trying to route IPv6 on Linux

I opened a ticket with my host on this. Since that fe80:1::4aa9:8aff:fe18:7bf9 isn't mine and appears to be coming from my host I'm guessing there is a routing issue for my /64. IMHO it looks like something is stealing my route like it's double routed or something. They've been "researching" for the past 2 days.

@patrickdickey52761 said in Verizon 5G Home Internet:

So let me ask this. Is there an easy way to allow IPv6 traffic through my WAN interface in such a way that all devices on the LAN side can get their addresses?

You could configure pfSense as just a firewall, without routing. A friend of mine just did that with OPNsense. This way you'll have a single /64 to work with on your LAN.

@artafinde said in IPv6 connectivity NAT:

DHCP6C logs

A WAN interface, igb0, became active, so dhcp6c starts doing its work :
The first part, where dhcp6c has process ID 867, goes well up until something/someone pulls the plug :

dhcp6c[867]: transmit failed: Network is down

So, djcp6c starts again : .... process ID is now 26116. It also ... vanishes.
New process again :

dhcp6c[26428]: transmit failed: Network is down

but 26428 manages to get everything right : an IPv6, a prefix
Reaching this phrase :

got an expected reply, sleeping
means all is well.

I'm not saying that these multiple restarts with 7 second are not normal, maybe you can set up an initial "10 seconds or so" hold off, see the dhcp4 parameters ? (not sure if the dhcp6 process has the same process option, you'll need to see the man ?)

I've this :

0c2adff7-6ab2-4b7e-973d-ef6f810bdc03-image.png

= nothing checked as you can see and it works fine for me.

I'm using pfSense + 24.11 .

The menu/settings structure is not exactly the same.

I believe I found the equivalents, and tried to apply them. I just could not get IPv6 to work on my LAN.

I even did a full factory reset of pfSense and started from scratch, following instructions in this thread. It's a no go.

I'm using a Comcast XB8 in bridge mode, but don't think the modem makes any difference. IPv4 works great, including inbound for my Wireguard VPN.

working now

New GUAs

https://redmine.pfsense.org/issues/15808

Should be in the next release 2.8/25.03
I think NAT64 might also come in that release.

I'm hoping for custom dhcp options in KEA, but the old dhcp is a fallback.

Then i need to wait for CLAT in Windows, which was talked about in a blog post last year, radio silence sinse then from MS

@Gertjan the alexas can dos my pihole all they want ;) that has zero to do with the cameras talking to the nvr, which is on an isolated network behind the nvr.

And they could cut the power to the house as well. The nvr is on a ups and the cameras are poe - so while it won't last days should be able to get good 30 minutes or so of run time.

Alexas in the landfill, what you have me do touch a light switch like a savage? ;)

@Bob-Dig That looks like it worked! Is there a limitation I should be aware of with how quickly those rules will update? I just don't want to leave an open hole in my firewall whenever my ISP drops the ball.

@Gertjan

Oh - good observation - you know, my ISP had many issues recently, and my modem had to be restarted.

Also, I added some new devices and reconfigured my DHCP server (new static mappings) several times recently.

It seems like it might correspond to those events. Could it simply be a remnant of that? Since it hasn't happened in several days, might everything be OK?

FYI:

root 69058 0.0 0.1 13024 2796 - Ss 24Jan25 1:10.52 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog

Yes, just one instance, dating back.

@Gertjan

OK, now I think I've hit a Heisenbug

I noticed the rule specified the same port in the "From" and "To" port range, and the surrounding text said to leave the "To" port blank for a single port. I blanked out the "To" port and committed the change, and the ipv6 ssh forwarding started working.

I made no other changes, and now the form fills in the "to" port with the same number, so it looks exactly like it did when it wasn't working.

It appears the rule just needed to be updated, but I have no idea why since the update didn't actually change anything.