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

@CZvacko

As I mentioned, you have to split into /64s. I suspect the ISP won't do that, as it's generally the customers responsibility. I'd suggest you put another pfSense between the ISP's gateway and your other pfSense boxes. That way it can split the /53 into 8 /56s, assuming that's what you want. You could use different addresses, as I suggested, to get to the right pfSense.

My question about IPv4 was assuming you didn't use NAT. If you can solve for that, you've got it solved for IPv6.

Do you have much experience with routers?

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.

@JonathanLee said in Alias tables don't contain IPv6 addresses anymore:

Is your zone transparent ? I had an issue with mine set to (type transparent) and it was causing issues

Zone type is at default "transparent" not "type transparent".

@jhg

Curious. I replaced the computer I originally ran pfSense on a few years ago. Other than changing the interface assignments, it just worked. I'm still using that new computer today. I'm on Rogers and they use a lot of the same hardware as Comcast. The first computer I ran pfSense on was a refurb HP compact computer and when it died I replaced it with the mini PC described in my sig.

Solved, and it's not pretty.

A debug message pointed me to /var/db/dhcp6c_duid containing text. So I removed the file to give DHCP6 a chance to start fresh. Then I disabled and re-enabled the WAN interface, and now everything's working.

When I look at that file now, it's binary, not text. Somehow, that file was preventing IPv6 connectivity.

Now all I have to do is reboot a few LAN devices that are hanging on to their old delegated prefix :-)

@JKnott After coming back to this a few days later all the wifi clients are now getting ipv6. Must of been some sort of delay from when the ISP gives out the ip addresses.