Implemented IPV6...Still Feel Left in the Dark!

[NollipfSense]

So, I have implemented IPv6 on my private cloud box using the configuration recommended here on the forum. All was going well until NAT; and, I was not ready when it came to the destination IP address...came to a standstill mentally for a few minutes. After glancing at the pfSense doc, I decided to use fc00::/64. Now, when I look at the dashboard, I don't see LAN with an IPv6 nor on my Mac pro...wondered why? Looking at Suricata alert, I can see IPv6 addresses on LAN...that's it...nothing else to indicate LAN IP address, not on Interfaces nor the Mac pro client...hence left in the dark...

[JKnott]

@NollipfSense said in Implemented IPV6...Still Feel Left in the Dark!:

All was going well until NAT

Why are you trying to use NAT? You should have a gazillion IPv6 addresses from your ISP.

[paoloposo]

If you want to use ULAs for a network, don't use fc00::/64. ULA prefixes must come from the fd00::/8 range. And you should also not use all zeroes for the positions up to the 48th bit, but rather generate a random prefix e.g. with this website.

As JKnott said, you shouldn't normally use NAT with IPv6. There are exceptions when it is necessary (e.g. VPNs that only give you one public address), but for normal use clients should either get an address from the ISP-provided prefix directly or, when using ULAs exclusively, you should use NPt. Note that you also can use GUAs with interface tracking and ULAs simultaneously.

Regarding the problem that the dashboard doesn't show the IPv6 address on the LAN interface: Have you applied the changes after saving?

[JKnott]

@paoloposo said in Implemented IPV6...Still Feel Left in the Dark!:

don't use fc00::/64. ULA prefixes must come from the fd00::/8 range

The original plan was for some public server to provide the prefix, to avoid the possibility of collisions, but I don't think that went anywhere. While this leaves the fc block free for user assignment of a prefix, I still use fd. If you really need to use fc, you must have a REALLY huge network.

[NollipfSense]

@JKnott I was just following here https://docs.netgate.com/pfsense/en/latest/nat/npt.html
as part of the configuration...so I don't need it?

[NollipfSense]

@paoloposo said in Implemented IPV6...Still Feel Left in the Dark!:

If you want to use ULAs for a network, don't use fc00::/64. ULA prefixes must come from the fd00::/8 range

I had tried fc00::/7 first but the interface say I must use /64...

[NollipfSense]

@JKnott said in Implemented IPV6...Still Feel Left in the Dark!:

While this leaves the fc block free for user assignment of a prefix, I still use fd. If you really need to use fc, you must have a REALLY huge network

Ah...okay...

@paoloposo said in Implemented IPV6...Still Feel Left in the Dark!:

Have you applied the changes after saving?

Yes...now I am thinking the NAT is messing things up.

[NollipfSense]

Could it be the prefix size or the DNS selection why IPv6 not showing on dashboard nor on client?

[NollipfSense]

This is what how I configured IPv6...

Interfaces > WAN > IPv6 Configuration Type > DHCP6
Use IPv4 connectivity as parent interface
Send IPv6 prefix hint 
Do not wait for a RA
LAN > IPv6 Configuration Type > Track Interface 
LAN > Track IPv6 Interface choose WAN
DHCPv6 Server >LAN > enable DHCPv6 Server
Enable router advertisement on LAN -Stateless

[JKnott]

@NollipfSense

Why are you using DHCPv6 on your LAN? Normally, SLAAC is used. Also, Android devices won't work with DHCPv6.

Here's how I set up ULA on my network.

[paoloposo]

@NollipfSense said in Implemented IPV6...Still Feel Left in the Dark!:

I had tried fc00::/7 first but the interface say I must use /64

That is correct, IPv6 subnets should always be /64. The ULA range is fc00::/7. However, the 8th bit must always be 1. Therefore, in practice, the usable ULA range is only fd00::/8. Your subnet must be within this range. In theory, fd00:0000:0000:0000::/64 (I've written it verbosely on purpose) is a valid IPv6 subnet. The problem is that if everyone were to use that, it would be a royal pain to merge networks should that ever be required. Therefore, it is strongly advised to generate a random /48 as the base prefix for all your local /64 networks. For example, when I visited the website I linked above, it generated fde5:cd68:8fb7::/48. So your local networks could be fde5:cd68:8fb7:0000::/64, fde5:cd68:8fb7:0001::/64, etc.

Also as JKnott said, DHCPv6 is normally not required and not all clients even support it. Always use SLAAC at least. You can use both if you want. Make sure to set the "Router mode" option correctly in the "Router Advertisements" tab of Services --> DHCPv6 Server & RA. If you want to use DHCP alongside SLAAC, select "Assisted".

[paoloposo]

The "Prefix Delegation Size" is only relevant in conjunction with "Prefix Delegation Range". Unless you want to delegate blocks of /64s to your clients instead of single addresses, you should leave this blank. An instance where this mechanism is used is when your ISP delegates a /48 or /56 to you.

[NollipfSense]

@JKnott said in Implemented IPV6...Still Feel Left in the Dark!:

Here's how I set up ULA on my network.

@paoloposo said in Implemented IPV6...Still Feel Left in the Dark!:

So your local networks could be fde5:cd68:8fb7:0000::/64, fde5:cd68:8fb7:0001::/64, etc.

I followed both and nothing is traversing LAN and no IP on LAN dashboard.

[JKnott]

@NollipfSense said in Implemented IPV6...Still Feel Left in the Dark!:

I followed both and nothing is traversing LAN and no IP on LAN dashboard

I suspect you've made so many changes, that things won't work. It might be better to start from scratch and follow the directions we've been providing. I've been running pfSense, including with IPv6 for almost 8 years and it works well for me.

[Gertjan]

@NollipfSense

Compare your :

with my :

Your DHCPv6 server hasn't a prefix (see Subnet) to work with ....

Check the DHCP6c on the WAN side (activate "DHCP6 Debug" on System>Advanced>Networking ) to be sure you obtained a (at least one) prefix.

[NollipfSense]

@JKnott said in Implemented IPV6...Still Feel Left in the Dark!:

I've been running pfSense, including with IPv6 for almost 8 years and it works well for me.

@Gertjan said in Implemented IPV6...Still Feel Left in the Dark!:

to be sure you obtained a (at least one) prefix.

For some unknown reason, it only started working after I configure from the cmdline...all is good...

[NollipfSense]

@Gertjan said in Implemented IPV6...Still Feel Left in the Dark!:

Your DHCPv6 server hasn't a prefix (see Subnet) to work with ....

How did you get your DHCPv5 server to show the WAN IP...had it in post #8 above. I am trying to get DHCPv6 server to work alongside RA; however, mine is showing my ULA IP and every range appears either outside the specified range, even with default :1000 - :2000 or a valid range must be specified...I am doing something wrong if I have 65,536 available...I put :0000:0009 - :0000:0154 or ::009 - ::0154 and I have ULA IP:: - ULA IP:0:ffff:ffff:ffff:ffff available range.

[Gertjan]

@NollipfSense said in Implemented IPV6...Still Feel Left in the Dark!:

How did you get your DHCPv5 server to show the WAN IP

After :
Set WAN to DHCP6 and just one setting in the "DHCPv6 Prefix Delegation size" : /64
Set the LAN interface up to tracking, where "Track IPv6 Interface" is set to WAN and selected

"0" here (no choice, just one prefix)

Now, when I activate the LAN DHCPv6 server, the prefix is shown as I've shown above, as it is known upfront : Delegated Prefix: WAN/0 (2a01:cb19:beef:a6dc::/64) : selected prefix "0" from the available 'range" (just 1 or 0 from 0) = 2a01:cb19:beef:a6dc:: with a standard /64 size.
The whole goal of using the DHCPv6 server is that is shouldn't use 'ULA" IPv6 .... (AFAIK).
The pfSense LAN (OPTx) DHCPv6 server should be one of the assigned (on the LAN/OPTx settings page) assigned to pfSense by an upstream DHCPv6 server, like my ISP router. Or it could even come from much farther upstream, your ISP equipment.
This obtained - by the pfSense WAN DHCPc6 client - prefix should be shown in the DHCP logs.

[NollipfSense]

@Gertjan It seems that my problem is that it does not show the Delegated Prefix despite DCHPv6 is enabled showing W/0...no IPv6 IP...then device gets an IPv6 IP despite Dashboard shows no LAN IPv6 IP...firewall shows no traversal...only if configure LAN interface via cmdline does it work but that uses the ULA...I did enabled IPv6 debug...

[Gertjan]

@NollipfSense said in Implemented IPV6...Still Feel Left in the Dark!:

I did enabled IPv6 debug...

dhcp6c logs ?

Like these : (read from bottom to top - it all happens in less then 30 ms)

2023-10-17 14:53:45.531447+02:00 	dhcp6c 	6769 	got an expected reply, sleeping.
2023-10-17 14:53:45.531395+02:00 	dhcp6c 	6769 	removing an event on ix3, state=RENEW
2023-10-17 14:53:45.531316+02:00 	dhcp6c 	6769 	script "/var/etc/dhcp6c_wan_script.sh" terminated
2023-10-17 14:53:45.530464+02:00 	dhcp6c 	68882 	dhcp6c renew, no change - bypassing update on ix3
2023-10-17 14:53:45.524339+02:00 	dhcp6c 	6769 	executes /var/etc/dhcp6c_wan_script.sh
2023-10-17 14:53:45.524316+02:00 	dhcp6c 	6769 	update a prefix 2a01:cb19:beef:a6dc::/64 pltime=600, vltime=1800
2023-10-17 14:53:45.524284+02:00 	dhcp6c 	6769 	update an IA: PD-0
2023-10-17 14:53:45.524261+02:00 	dhcp6c 	6769 	Domain search list[0] home.
2023-10-17 14:53:45.524238+02:00 	dhcp6c 	6769 	nameserver[0] 2a01:cb19:907:a600:46d4:54ff:fe2a:3600
2023-10-17 14:53:45.524202+02:00 	dhcp6c 	6769 	dhcp6c Received INFO
2023-10-17 14:53:45.524179+02:00 	dhcp6c 	6769 	get DHCP option domain search list, len 6
2023-10-17 14:53:45.524158+02:00 	dhcp6c 	6769 	get DHCP option DNS, len 16
2023-10-17 14:53:45.524139+02:00 	dhcp6c 	6769 	preference: 255
2023-10-17 14:53:45.524119+02:00 	dhcp6c 	6769 	get DHCP option preference, len 1
2023-10-17 14:53:45.524094+02:00 	dhcp6c 	6769 	IA_PD prefix: 2a01:cb19:beef:a6dc::/64 pltime=600 vltime=1800
2023-10-17 14:53:45.524068+02:00 	dhcp6c 	6769 	get DHCP option IA_PD prefix, len 25
2023-10-17 14:53:45.524048+02:00 	dhcp6c 	6769 	IA_PD: ID=0, T1=300, T2=480
2023-10-17 14:53:45.524028+02:00 	dhcp6c 	6769 	get DHCP option IA_PD, len 41
2023-10-17 14:53:45.524008+02:00 	dhcp6c 	6769 	DUID: 00:03:00:01:44:d4:54:2a:36:00
2023-10-17 14:53:45.523982+02:00 	dhcp6c 	6769 	get DHCP option server ID, len 10
2023-10-17 14:53:45.523961+02:00 	dhcp6c 	6769 	DUID: 00:01:00:01:2b:5a:d7:6b:90:ec:77:29:39:2c
2023-10-17 14:53:45.523929+02:00 	dhcp6c 	6769 	get DHCP option client ID, len 14
2023-10-17 14:53:45.523896+02:00 	dhcp6c 	6769 	receive reply from fe80::46d4:54ff:fe2a:3600%ix3 on ix3
2023-10-17 14:53:45.505302+02:00 	dhcp6c 	6769 	send renew to ff02::1:2%ix3
2023-10-17 14:53:45.504977+02:00 	dhcp6c 	6769 	set IA_PD
2023-10-17 14:53:45.504957+02:00 	dhcp6c 	6769 	set IA_PD prefix
2023-10-17 14:53:45.504934+02:00 	dhcp6c 	6769 	set option request (len 4)
2023-10-17 14:53:45.504912+02:00 	dhcp6c 	6769 	set elapsed time (len 2)
2023-10-17 14:53:45.504893+02:00 	dhcp6c 	6769 	set server ID (len 10)
2023-10-17 14:53:45.504873+02:00 	dhcp6c 	6769 	set client ID (len 14)
2023-10-17 14:53:45.504848+02:00 	dhcp6c 	6769 	a new XID (806046) is generated
2023-10-17 14:53:45.504824+02:00 	dhcp6c 	6769 	Sending Renew
2023-10-17 14:53:45.504791+02:00 	dhcp6c 	6769 	reset a timer on ix3, state=RENEW, timeo=0, retrans=9648
2023-10-17 14:53:45.504702+02:00 	dhcp6c 	6769 	IA timeout for PD-0, state=ACTIVE

It looks a bit like DHCPv4 : the client set some options, and fires a request to the server.
Identification isn't MAC based, but "dude" (DUID) based.
"2a01:cb19:beef:a6dc::/64" is the prefix pfSense received - and is used for the DHCPv6 server on LAN.