@johnpoz Got it, thanks! Somehow totally missed that page. One DHCP lease renew later and everything seems to be working good now.

@viktor_g Thanks so much for your help. After applying the second patch things are working as expected. Thanks again.

Hmm, maybe adding a static route would solve this? If you go to System, Routes and Static routes.

It seems that I have found the issue...
By analyzing the tcpdump, I have noticed that there was another ip that was answering to the request of the dhcp.
The problem is that I didn't know what it was. It was in the ndp table of my computer, it was in the neighbour list of the switch.
At the end it was a stupid raspberry that was advertising itself as router. Disconnected, everything works like a charm.
Thanks for the help anyway. Case closed!

@JKnott said in LAN unable to talk over WAN IPv6 after reboot or reinstall of Suricata:

@OffstageRoller said in LAN unable to talk over WAN IPv6 after reboot or reinstall of Suricata:

I mentioned in my OP that when this happens, I can both ping and ping6 from the pfSense box itself. It's only my local network that can't talk over IPv6 to the public internet.

You have to test various things to isolate the problem. You were able to ping from pfSense, so that shows the WAN connection works. When you try from the LAN and watch the WAN, you can determine if the problem is with pfSense or elsewhere. This sort of thing is just basic troubleshooting. You try to isolate where the problem is coming from.

That was something RMO asked initially, and yes, my default deny IPv6 rule is blocking my LAN from reaching the internet over IPv6. Almost all of my rules have the source (LAN net) that matches the interface where the rule exists. And it appears that after a reboot, the devices that have DHCP6 addresses are not considered part of that LAN net source, and therefor they get caught by the default deny rule.

Interestingly enough, I did what you suggested in RMO's thread and enabled Do not allow PD/Address release and that appears to have fixed my issue. Should it have though?

I would expect that might be the case if you had addresses hard coded somewhere and the prefix changed.

But they're not hard coded, and my IPv6 prefix does not change :).

However, after a reboot, pfSense does not appear to be storing the IPv6 prefix in my "net" source rules I mentioned above. And it's only after I renew my DHCP lease (which doesn't change the lease), that that my pass rules start allowing IPv6 through, that something gets updated within pfSense and my prefixes for each /64 LAN are now stored in the "LAN net" rule. Hopefully that makes sense?

I'm happy to test other scenarios to help narrow things down further.

@daygle said in IPv6 DHCPv6 Leases Not Being Assigned on pfSense LAN Network:

No matter what I change I just cannot seem to see any leases in the 'DHCPv6 Leases' section. Am I missing something? Hoping someone is able to point me in the right direction to enable IPv6 on my LAN.

Is your modem in bridge or gateway mode? It has to be in bridge mode. If in gateway, only devices directly connected to it will get IPv6 addresses. For example, I get a /56 prefix from my ISP, with the modem in bridge mode, which pfSense can then split into 256 /64s. In gateway mode, I only get as single /64, which cannot be passed through pfSense.

@cmcqueen

I'm in Canada, so it's not an Aussie thing. As for why it's there, previously it wasn't and the prefix would frequently change. I suppose there is a reason why someone would want to always release the prefix, but I don't know what that is, other than perhaps changing ISP or something.

Yes the IPv6 address on your tunnel interface would be the tunnel IPv6.. Why and the F would you care what it is or if its your /48 or not..

This is the transit network, this is how it would be on a routed IPv4 network as well..

There is no nat going on in the ipv6, the /48 is routed to you..

@jimp said in IPV6 leases now showing up:

ChromeOS does not support obtaining addresses via DHCPv6 (Nor does Android), only via SLAAC.

https://support.google.com/chrome/a/answer/9211990?hl=en

Thanks a million, my google foo was very off.

@Katan said in Loosing IPV6 connectivity after 1 hour with HG8245Q2 (OI Firmware):

And thanks for your help so far.

I don't know what you've done so far, but sometimes it's easier to start from scratch,rather than try to find the cause of a problem, particularly if you've been trying a lot of things.

@Lou-Erickson said in Struggling to get basic IPv6 working...:

My copy of "IPv6 Essentials" has arrived

That is an excellent book for IPv6, though it's about the general principles and doesn't get into connecting to an ISP, DHCPv6-PD, etc.. It's also a good idea to use Wireshark, to examine what's actually on the wire.

BTW, I have copies of that book on both my computer and tablet.

@S_Alex

Here's something you can try that might provide some useful info. Disconnect the WAN cable. Run Packet Capture, filtering on DHCPv6 and then reconnect the WAN cable. Download the capture and post it here. I'm assuming they use DHCPv6.

@meluvalli

Do a capture packet on DHCPv6 and one of the client addresses to see what's happening.
Also, check the lease time. The client should not lose the address before the lease expires.

Yes, sorry, I was not very precise regarding the "not to use IPv6 for internal communication for now". I meant more I'm not using it explicitly like e.g. having DNS entries for my local servers (NAS etc.), having firewall rules that allow specific IPv6 traffic (e.g. from or to specific hosts between VLANs) etc..

Generally, I want to push IPv6 as far as possible, but without any compromise or "ugly" setups. IPv6 addresses are running out and in my opinion everyone should do their part moving to IPv6 (and I'm also very interested in it ;) ). And IPv6 definitely has its advantages, e.g. like getting rid of NAT. (Using NPt is fine from my perspective, because it's 1:1 without any state, and it's very helpful e.g. for Multi-WAN setups.)

My setup looks like this:

I have two ISPs that support full DualStack with dynamic /56 prefixes via DHCPv6. But because of https://redmine.pfsense.org/issues/6880 I have disabled IPv6 completely for "WAN2" (actually OPT1 ;) ). (As soon as this issue is solved, I maybe use WAN1 for some VLANs and WAN2 for others. Currently for IPv4 I have a setup where some VLANs use WAN1 with fallback to WAN2 and for some others the other way around.) For most VLANs I have IPv6 enabled using "track interface", but for some I have disabled it. I use "Stateless DHCP", so SLAAC for address configuration. (DHCP e.g. to distribute the name server, but my DNS doesn't include any local DNS entries apart from the one of pfSense that pfSense adds automatically.) I block basically all IPv6 communication between VLANs using a block rule with "xxx net". I need this, because I want to allow Internet traffic where I need an "allow to any". I haven't found any other way to block IPv6 traffic between my VLANs, but allow it for Internet. For IPv4 it's easily done with one "block 192.168.0.0/16" rule, but as discussed above this doesn't work when I get my prefix dynamically via DHCP without a variable or an automatically generated alias that contains the whole prefix or whatever. The downside with the "xxx net" approach is that for n VLANs you need n*n rules (so in my setup 5*5=25) instead of just n, or even 0, because with an alias I could already exclude local traffic from the "allow to any" rule. I "don't care" (at least in the context of this discussion) what happens within my VLANs, because when IPv6 is used there somewhere "automatically", it's just an implementation detail. If I want to control the traffic within a VLAN, I have to go down to layer 2. What does it help when I block IPv6 there and the devices use another never-heard-of protocol on top of layer 2. My switches (Cisco SG300) have some layer 2 filtering capabilities I think, but I haven't used it so far.

Well, I think that's it basically. I will move on further as soon as more pfSense features support dynamic prefixes. For example when 6880 is solved and NPt support dynamic prefixes, I will try to extend my Multi-WAN setup to IPv6. As I will then also have ULAs, I will probably then also set up IPv6 DNS entries for my NAS etc. Haven't thought about how to allow only individual hosts to some destinations then (regarding the temporary address problem), but I think I still have some time to think about that before I get to that point. ;) But probably that's not even an issue, because I think all use cases where I need this is some kind of server-to-server communication (e.g. mail server to NAS for backups) that don't need temporary addresses anyway.

@tpalmer0127

What does your ISP provide? Earlier you said /48.

There are coming back but there are no going out. Even the hosts I‘ve never heared.

Don't feel too bad the DOD is still dicking around with even trying to roll out dual stack support ;) And they have been at its since 2003 ;)

@RobertTheSwede

WOW, that is dumb. I have a /56 and have used prefix ID ff for my VPN without issue. Works fine. Their policy should be everything in that /48 prefix should be forwarded to the customer. Also, it's extremely unlikely there would be any traffic for an unused prefix, as there is nothing to trigger it.