IPv6 + DHCPv6 + statefull

robsonvitorm

Hi!

I'm deploying IPv6 at the company where I work. Our provider assigns us a /48 prefix. On the provider's router interface, the IP is set to ::1, and they route the /48 prefix to ::2, which is configured on the WAN interface of my pfSense.

For the VLANs, I created /64 subnets—for example, 10::1 (set as a static address on the VLAN interface), making it the gateway for that network.

I configured Router Advertisement to send packets on the VLAN and set the mode to Managed (stateful).

In Kea-DHCPv6, I defined the available range within the /64 subnet for the VLAN (e.g., 10:1001 - 10:1002).

My issue is that DHCPv6 is not assigning IPs to hosts at all. It only works when I manually set a static IPv6 address on the hosts. Even then, IPv6 communication only starts after I send a ping6 from the pfSense to the statically assigned host IP.

Analyzing the NDP table, I noticed that before the ICMPv6 request from pfSense, the host's IPv6 address is missing from the NDP table. If I try sending ICMPv6 from the host to the pfSense before triggering it on the pfSense side, the address (e.g., 10:1) is not found on the network.

To rule out packet filtering issues, I allowed all IPv6 traffic on the VLANs, but DHCPv6 still doesn't work.

If I switch to Stateless (SLAAC), everything works fine, but I need it to be Stateful.

I asked the provider if they were using Prefix Delegation, but they confirmed that they are not, and they fully route the prefix to ::2.

I checked the switches for any multicast filtering issues but found nothing. I'm using Aruba Instant On 1930 switches.

Running a tcpdump, I noticed that DHCPv6 requests never reach the pfSense on port 547, but I do see RS, RA, NS, and NA messages.

My pfSense runs in a virtual machine with direct traffic passthrough to physical interfaces.

I need to understand if I'm missing something or if this could be a bug.

Thanks!

patient0

@robsonvitorm are the clients configured to request IPv6 per DHCP? Often SLAAC is the default (or as for Android devices, SLAAC is the only thing they support).

Can you show/explain a client's interface configuration? And/Or do you see DHCP requests leaving the clients at all?

Gertjan

@robsonvitorm

How did you configure your LANs - the IPv6 part ?
Statically ? Ok-ish.
Tracking ? If possible, this would be best.

If the IPv6 capabilities of an LAN interface are set, the DHCPv6 server of that interface will be activated :

Note : I use IPv6 "Tracking" on my LAN :

so pfSense will ask on it's WAN connection, from a IPv6 upstream router (or ISP) my IPv6 prefixes.
One prefix for every LAN type interface. ( a /48 is good for 65535 prefixes, so 65535 LANs. Please post back here if you have a pfSense with 65535 LAN's ;) )
One of the prefixes will get auto assigned to the LAN interface - and LAN interface DHCPv6 server.
So no need for me to type in any IPv6 related stuff - no where. Its all handled as by magic.

Static setup is also possible :

First :

and on the same page :

where "2a01:dead:beef:1000::" is part of the /48 that is assigned to you (double check this - you are not allowed to assign something that doesn't belong to you )

When saving your LAN page settings, goto the LAN DHCPv6 server page, and give it a IPv6 pool, like
Start : 2a01:dead:beef:1000::100
End : 2a01:dead:beef:1000::200

for 200 different devices.

and done : Save Apply, and DHCPv6 is up an running for LAN.

The beauty of all this : it looks like habits we got with the DHCPv4.
Just one major difference : you're not dealing with RFC11918 stuff, but real global rout-able IPv6 addresses.

@robsonvitorm said in IPv6 + DHCPv6 + statefull:

If I switch to Stateless (SLAAC)

Never needed to used it.

I'm using 24.11 - actually 25.03 beta, and I've also set :

robsonvitorm

Hi, @patient0

Yes, they are set to obtain an IP via DHCP. For Android, I'll link the user and IPv6 address to authentication with Radius.
I'll attach some images from an attempt to obtain an IP. Take a look:

Screenshot_vm-teste_2025-04-03_09:05:24.png

JKnott

@robsonvitorm said in IPv6 + DHCPv6 + statefull:

On the provider's router interface, the IP is set to ::1

That is the IPv6 loopback address. It shouldn't be on a physical interface. Also, is there some reason you're using DHCP6 for the clients? Unless you have some specific reason for it, you're better off with SLAAC.

Gertjan

@robsonvitorm

The pfSense equivalent :

When I run a
ipconfig /renew6
on my Windows PC,
I'll see this getting captured :
The request from the PC :

15:48:58.171202 IP6 (flowlabel 0xf099d, hlim 1, next-header UDP (17) payload length: 141) fe80::a6bb:6dff:feba:16a1.546 > ff02::1:2.547: [udp sum ok] dhcp6 renew (xid=642363 (elapsed-time 0) (client-ID hwaddr/time type 1 time 643424141 a4bb6dba16a1) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:161790829 T1:6750 T2:10800 (IA_ADDR 2a01:dead:beef:a6e2::c7 pltime:13500 vltime:21600)) (vendor-class) (Client-FQDN) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))

and the answer from pfSense DHCPv6 LAN server :

15:48:58.181371 IP6 (hlim 64, next-header UDP (17) payload length: 173) fe80::92ec:77ff:fe29:392c.547 > fe80::a6bb:6dff:feba:16a1.546: [udp sum ok] dhcp6 reply (xid=642363 (client-ID hwaddr/time type 1 time 643424141 a4bb6dba16a1) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:161790829 T1:6750 T2:10800 (IA_ADDR 2a01:dead:beef:a6e2::c7 pltime:13500 vltime:21600)) (DNS-server 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c) (DNS-search-list bhf.tld.) (Client-FQDN))

This implies :
The request from the device reached the server.
The server handled the request.
On the PC I can see that the request was accepted : the end-of-lease (or nrenew time) changed.

In your tcpdump, executed on your Debian, I see only the requests send from the DHCP client to the server.
Can you show, as I've shown, what de server received ?
Did it answer ?
Was it running ?

ps aux | grep 'dhcp'

Btw : DHCP : Kea or ISC ? : Edit : Kea.
What pfSense version ?

robsonvitorm

Hi, @JKnott, I just masked the full prefix—the address follows the complete format, like 2001:...::1.

robsonvitorm

This post is deleted!

robsonvitorm

Hi, @Gertjan.

How did you configure your LANs - the IPv6 part ?
R: Static IPv6
Tracking ? If possible, this would be best.
R: the provider does not have this option, only fixed

See the settings:

DHCPv6

Router advertisement

WAN

VLAN

Thanks!

robsonvitorm

@Gertjan I'm using version 2.7.2

@Gertjan said in IPv6 + DHCPv6 + statefull:

In your tcpdump, executed on your Debian, I see only the requests send from the DHCP client to the server.
Can you show, as I've shown, what de server received ?
Did it answer ?

Yes, the server:

tcpdump -vvnn -i vtnet1.18 "icmp6 && (ip6[40] == 133 || ip6[40] == 134 || ip6[40] == 136) || (udp port 546 or 547)"

Capture:

patient0

@robsonvitorm maybe to do with the VLAN, are the clients supposed to get an IPv4 per DHCP, does that work? Your screenshot doesn't show neither an IPv4 nor IPv6.

The client is a VM too I assume from the hostname? And the switch/port to the client fully support VLANs? And the neccessary ports are configured for VLAN trunking?

Addition: On a VM setup with CE 2.7.2 I have set on LAN a static IPv6 (ULAs) and the client get's an IP from the KEA pool ::d:1000 - ::d:1999.

robsonvitorm

@patient0 said in IPv6 + DHCPv6 + statefull:

@robsonvitorm maybe to do with the VLAN, are the clients supposed to get an IPv4 per DHCP, does that work? Your screenshot doesn't show neither an IPv4 nor IPv6.

Yes, it works for IPv4. Only IPv6 doesn't work.
This is a virtual machine, but when testing with physical machines, I get the same result. Yes, the VLAN support switch is untagged and PVID with VLAN 18.

@patient0 said in IPv6 + DHCPv6 + statefull:

Addition: On a VM setup with CE 2.7.2 I have set on LAN a static IPv6 (ULAs) and the client get's an IP from the KEA pool ::d:1000 - ::d:1999.

sorry, I didn't understand this part, was it a statement?

patient0

@robsonvitorm said in IPv6 + DHCPv6 + statefull:

Yes, the VLAN support switch is untagged and PVID with VLAN 18

Ok, I was wondering because in the client screenshot the interface is named ens3.18 which would have indicated that you expect the traffic to arrive tagged.

sorry, I didn't understand this part, was it a statement?
Yes :) ... KEA is pretty much a preview on 2.7.2 and I wanted to make sure it works (at all, in my test).

You could switch to ISC DHCP and see if it runs better (System > Advanced > Networking)

robsonvitorm

@patient0 said in IPv6 + DHCPv6 + statefull:

Ok, I was wondering because in the client screenshot the interface is named ens3.18 which would have indicated that you expect the traffic to arrive tagged.

@patient0 Sorry, I got mixed up—this VM is tagged, but the physical machines are untagged.

As for switching to ISC, that’s something we’re considering internally. I can’t find any reason why this isn’t working—it’s a very simple setup that shouldn’t be taking up this much time.

patient0

@robsonvitorm said in IPv6 + DHCPv6 + statefull:

I can’t find any reason why this isn’t working—it’s a very simple setup that shouldn’t be taking up this much time.

You are right, it really should work. But before invest even more time do the switch and verify that there no Layer 2 issue.

There are a few thread about the KEA vs ISC DHCP, e.g ISC DHCP has reached eol and will be removed in a future version of Pfsense.

Gertjan

@robsonvitorm said in IPv6 + DHCPv6 + statefull:

tcpdump -vvnn -i vtnet1.18 "icmp6 && (ip6[40] == 133 || ip6[40] == 134 || ip6[40] == 136) || (udp port 546 or 547)"

Thanks for the command !
(but the radv IPv6 bla bla traffic is also spamming )

Your image shows the - I think - the DHCPv6 server == pfSense answer.
So it received a request. And answered.
From a pfSense pint of view, DHCPv6 works.

Here is a sequence from mine :

Client to server
22:37:59.295387 IP6 (flowlabel 0x58369, hlim 1, next-header UDP (17) payload length: 141) fe80::a6bb:6dff:feba:16a1.546 > ff02::1:2.547: [udp sum ok] dhcp6 renew (xid=b34e82 (elapsed-time 0) (client-ID hwaddr/time type 1 time 643424141 a4bb6dba16a1) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:161790829 T1:6750 T2:10800 (IA_ADDR 2a01:cb19:907:a6e2::c7 pltime:13500 vltime:21600)) (vendor-class) (Client-FQDN) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))

server to client
22:37:59.315289 IP6 (hlim 64, next-header UDP (17) payload length: 173) fe80::92ec:77ff:fe29:392c.547 > fe80::a6bb:6dff:feba:16a1.546: [udp sum ok] dhcp6 reply (xid=b34e82 (client-ID hwaddr/time type 1 time 643424141 a4bb6dba16a1) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:161790829 T1:6750 T2:10800 (IA_ADDR 2a01:cb19:907:a6e2::c7 pltime:13500 vltime:21600)) (DNS-server 2a01:cb19:907:a6e2:92ec:77ff:fe29:392c) (DNS-search-list brit-hotel-fumel.net.) (Client-FQDN))

client to server
22:37:59.568116 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::a6bb:6dff:feba:16a1 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): a4:bb:6d:ba:16:a1
            0x0000:  a4bb 6dba 16a1

server to client
22:37:59.568669 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 152) fe80::92ec:77ff:fe29:392c > fe80::a6bb:6dff:feba:16a1: [icmp6 sum ok] ICMP6, router advertisement, length 152
        hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): 2a01:dead:beef:a6e2::/64, Flags [onlink], valid time 86400s, pref. time 14400s
            0x0000:  4080 0001 5180 0000 3840 0000 0000 2a01
            0x0010:  dead beef a6e2 0000 0000 0000 0000
          route info option (24), length 8 (1):  ::/0, pref=medium, lifetime=1800s
            0x0000:  0000 0000 0708
          rdnss option (25), length 24 (3):  lifetime 1800s, addr: 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c
            0x0000:  0000 0000 0708 2a01 dead beef a6e2 92ec
            0x0010:  77ff fe29 392c
          dnssl option (31), length 56 (7):  lifetime 1800s, domain(s): bhf.tld.
            0x0000:  0000 0000 0708 1062 7269 742d 686f 7465
            0x0010:  6c2d 6675 6d65 6c03 6e65 7400 1062 7269
            0x0020:  742d 686f 7465 6c2d 6675 6d65 6c03 6e65
            0x0030:  7400 0000 0000
          mtu option (5), length 8 (1):  1500
            0x0000:  0000 0000 05dc
          source link-address option (1), length 8 (1): 90:ec:77:29:39:2c
            0x0000:  90ec 7729 392c

Looks like the client requests,
and the server answers 'something',
Then the client makes a second requests
and the server answers with all the details.

robsonvitorm

Hi @Gertjan,

Thanks for send your example.

Today I got back to working on the IPv6 deployment in my network and decided to take a different approach, since multicast packets really weren’t reaching pfSense—something quite odd. So I started troubleshooting at Layer 2 and finally found the issue.

Since my pfSense runs virtualized with libvirt, I began digging into potential multicast issues related to libvirt’s network interfaces. I’m using macvtap with virtio to provide smoother network passthrough to the VM.

On a forum, someone mentioned a parameter (trustGuestRxFilters) that needs to be enabled on the interface to allow multicast traffic. By default, it’s disabled. I checked the documentation, and it turned out to be true. Once I enabled the parameter, DHCPv6 started working immediately.

<interface type="direct" trustGuestRxFilters="yes">
  <mac address="52:54:..."/>
  <source dev="fw_lan" mode="bridge"/>
  <target dev="macvtap3"/>
  <model type="virtio"/>
  <alias name="net1"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
</interface>

@Gertjan, @patient0, and @JKnott – thank you all for taking the time to help us work through this issue. I'm really grateful to be part of such an active community, full of helpful and kind people!

I hope this experience proves helpful to others who might run into the same issue.
All the best!