I am not familiar with your ISP so can't be specific, but a few things to double check- You did set the prefix delegation under WAN/DHCP 6 CLIENT CONFIG, and try with prefix hint set ON and OFF?

@Hikari

The /x indicates the prefix length. Your LAN gets a /64 prefix, which means 64 bits for the network address, leaving 64 for the device within the LAN. A /128 means the entire 128 bits is prefix leaving no bits for more than 1 device. I doubt it would have anything to do with the MAC, as it's assigned by DHCP. If it was MAC based, it would be obvious. Your LAN gateway demonstrates the link local address is used, not a public address.

@JKnott said in Multiple /64 ULA subnets sharing same WAN /64 prefix via NPTv6?:

It's amazing how CHEAP some ISPs are, considering the IPv6 address space is so vast. While my ISP initially provided a single /64, that was only temporary and they soon moved to /56. Then there's he.net, which will provide a /48 for free! Before my ISP offered IPv6, I used a tunnel and got a /56 again for free.

BTW, the address space is so vast that every single person on earth could have over 4000 /48s and that's with only 1/8th of the entire address space assigned to anything.

My ISPs don't even offer more expensive plans, not that I'd accept paying. A tech even told me that only government companies are forced to follow IPv6 standards. As it's a private ISP company, they can use proprietary protocols, and it's my problem if Internet doesn't work fully. Another one told me that I'm "welcome" to cancel the contract if I want to.

Indeed, according to IPv6 standard, every ISP receives at least a /32 prefix. With it, these 2 ISPs have more /56 prefixes than IPv4 addresses.

@nva said in Multiple /64 ULA subnets sharing same WAN /64 prefix via NPTv6?:

My ISP only route single /64 subnet to resident connection. I'm planning to deploy ULA for each of my VLANs and then NPT to that public /64 prefix assigned by ISP. Do I need to worry about suffix conflict?

Is there any drawbacks (e.g. latency...) in deploying ULA + NPt compared to just GUA via Track interface? The only problem i can think of is that I would need to manually adjust NPt entries every time my ISP routed prefix change and will try to get it working.

Were you able to get it to work? That's what I was considering doing on my OpenWRT a couple years ago but got tired after 2 long fights with both ISPs. Now I'm considering moving to pfSense because of some BusyBox limitations.

Are you able to update your VLANs prefixes when your ISP changes it?

One ugly thing I consider doing is choosing a random /60 prefix from one of my ISPs /32 and setting it as base for my VLANs. ALAIK, some OSs will use IPv4 if only ULA is provided for them, because it implies that no Internet is available on IPv6, even if router manages ULA to GUA correctly.

Using a global prefix that's not delegated to me breaks me from reaching out any device that's on that prefix, but I don't access any residential IP other than mine anyway.

@JKnott You can delegate prefixes. An address is assigned and the delegated prefix is routed to it.

e25444ec-ae09-48a2-883d-650b75f7ff52-image.png

https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6.html#dhcpv6-prefix-delegation

Don't lose hope... it's been just less than a month since it started working for me, so they may have re-started testing.

The only places I'm aware of it being available so far are select areas in Northern and Central VA (areas served by five different Verizon central offices have been confirmed) and Waltham MA (where a Verizon Technology Development Center is - or at least was - located).

But determining what areas it might be available in is kind-of off topic for here since that's not directly pfSense-related. The settings to make it work are above, and there's also a script you can set up to detect when Verizon is sending out IPv6 router advertisements in your area.
https://forum.netgate.com/topic/137478/fios-users-waiting-for-ipv6-script-to-let-you-know-when-it-s-ready

There's a topic over in the FiOS forum on DSLReports that might be a better place for tracking availability. Don't feel the need to read all 2 years worth of posts... the most current list is within the last two pages (and was just quoted by someone on the last page).
https://www.dslreports.com/forum/r32136440-Networking-IPv6-working

Fixed in upstream, see https://redmine.pfsense.org/issues/10757

@carloabelli

Unlike IPv4, ICMP is essential with IPv6. I have a rule on my WAN that allows all ICMP on both 4 & 6.

Well... in the packet capture, the MAC address of the Ethernet frame matches the MAC address of the default gateway from my ISP (which is not unusual when dealing with packets being routed to you). But the IPv6 address is definitely not the same, and it doesn't appear to be an EUI64 address, so I can't match it to a MAC address. I do realize that I masked part of the address that would have identified that fact.

It's likely a misconfiguration on my ISP's part... they only just got IPv6 up and running about a week ago, and it may not even be completed yet (But I've figured out how to make it work with pfSense, not knowing whether their own routers even work with it).

It's kind-of annoying that this is logged in the general system log though...it'd be nice if it were in the routing log... but I assume since it's the kernel generating these messages, that's why it's in the system log.

That was exactly what I needed. Thank you so much!

I have been working on a similar setup. Dual WAN IPv4+IPv6. I get native IPv4 from my ISP. For IPv6 I have been using Hurricane Electric for at least a decade. Recently, I stumbled upon a tunnel service that does both IPv4 and IPv6. This makes it possible to rather easily move services, yet keeping IPs the same, both IPv4 and IPv6.

But that's more of a backstory. I have been researching quite the same problem you describe. Packets that are generated on the router (e.g. ICMP TTL Exceeded when doing a traceroute) should be sent back through the same interface they entered, but for IPv6, this doesn't work.

It seems that in FreeBSD, the backing operating system for pfSense, this is simply not implemented for IPv6. There is code in review for this, but it may take some more time before that reaches FreeBSD itself, and consequently pfSense.

Hope this helps.

With thanks to Netgate tech support, the solution was to turn off my interface's Block private networks and loopback addresses. Upon reflection, this does make sense and with it disabled, my DHCPv6 server with RA set to either managed or assisted is now responding to DHCPv6 client requests and issuing assignments.

And yet, I will submit a feature request such that when the DHCPv6 Server is enabled, an alert should be posted saying "but you need to disable Block private networks and loopback addresses on the interface, otherwise the DHCPv6 server will never receive the incoming IPv6 client's request for a local RA server..."

@rajeshh
That's called "dual stack" and will be needed for a while yet. If the games support IPv6, then it will work that way for you. The operating systems prefer IPv6, but will use IPv4 when necessary.

Of course as soon as I post this I redid it with a new vhid and a FULLY expanded ipv6 address. No :: no :0: and no :3: was done, that fixed it and my routes came up with the upstream router.

I still would like to find that redmine issue so I can track the fix. If anyone knows the # I would appreciate it.

Thanks

me too, what this is?

Aug 24 05:38:00 kernel sa6_recoverscope: embedded scope mismatch: fe80:c::f298:38ff:fe93:d380%13. sin6_scope_id was overridden

@HG

You also have to look at how often DHCPv6-PD executes and whether it does after PPPoE comes up. I have a capture of DHCPv6 at boot up and the first renewal and it's over 22 hours between them.

Hey, I'm not sure if this is still relevant but restarting the service at status>gateways fixed it for me. However, I was already able to ping my IPv6 gateway from the diagnostics>ping tool.

Untitled (2).png

@johnpoz

Config is done and working as expected.

Got a /48 from HE and /50 subnets to LAN.

9fc6b336-5d05-4538-b512-87464720b176-image.png

DHCPv6 Server & RA (/56 to downstream CPEs)

8466e9df-c67d-489c-a7cf-09743b7f7b14-image.png

RA

3bffbe77-935e-49ce-b134-6c532079aa6b-image.png

Tested with Android 8/9, Android TV 7.1.2, iOS 9.3.6, Windows 10, Arch Linux, OpenWRT, and some others Home Gateways.

@qsystems If you are using Unifi APs (Multicast Enhancement, rings bell for those) make sure you have the latest firmware loaded, they have had some issues with multicast recently and supposedly corrected with newer firmware.

Just FYI: the issue https://redmine.pfsense.org/issues/2358 got that pull request #4405 so it should go into review now.

@kesawi said in Planning for IPv6 /48 allocation:

My question for anyone who may know, is it possible to have two separate concurrent DHCPv6 scopes with pfSense and Windows? If so what do I need to do to get it to work?

I doubt it, as there would be no way to determine which DHCPv6 server was desired.

I assume if I give up on DHCPv6 and just go to SLAAC for both then ULA and GUA will still co exist?

That's what I have. Also, if you have Android devices, you don't want to use DHCPv6. For some idiotic reason, Android doesn't support it.

I have two internal DNS severs. Do I need to specify both their respective ULA and GUA addresses in the RA settings, or can I just specify the ULA addresses?

You can use either GUA or ULA address. However, you don't have to specify an address as pfSense does that by default. It uses it's own address, unless you specify otherwise.

@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!

@RMO issues created:
https://redmine.pfsense.org/issues/10712
https://redmine.pfsense.org/issues/10713
https://redmine.pfsense.org/issues/10714
https://redmine.pfsense.org/issues/10715

you can register on the redmine.pfsense.org and leave any extra comments

@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.