IPv6 + DHCPv6 + statefull

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!