IPv6 SLAAC not working and Wrong IPv6

[gigagames]

Hello,
since i upgraded opnSense to Version 24 IPv6 is somewhat broken for me.
My setup:
Currently Version 24.1.2_1

WAN (1 Port):
Prefix delegation /59
Send prefix hint
Use IPv4 connectivity

LAN (2 Ports, running as LACP)
Clients – VLAN 100 | IPv6 Track WAN Prefix ID 0x2 | Received IP 2a01:xxxx:xxxx:dc02:2d0:b4ff:fe01:de3f
GuestWiFi – VLAN 110 | IPv6 Track WAN Prefix ID 0x1 | Received IP 2a01:xxxx:xxxx:dc01:2d0:b4ff:fe01:de3f
Server – VLAN 30 | IPv6 Track WAN Prefix ID 0x3 | Received IP 2a01:xxxx:xxxx:dc03:2d0:b4ff:fe01:de3f

Now I have a LXC running inside of Proxmox where I set the VLAN to 30 and IPv6 to SLAAC. The LXC doesn’t receive any IPv6.
If I change the LXC to DHCPv6  I receive an IPv6 but from the Wrong interface (2a01:xxxx:xxxx:dc01::2000) Thats an IP from the GuestWiFi not from the Server Interface.

What’s going on?

[meyergru]

FreeBSD does not work too good with mixing tagged and untagged VLANs - your LAN seems untagged, plus it also runs on a LAGG.

From the looks of it, there is some mixup of VLANs such that the GuestWiFi somehow gets to your server. You can chase it down with tcpdump, because it is unclear if it is OpnSense, your switch or the Proxmox server which is the culprit.
 

[gigagames]

@meyergru thanks for you reply

I have run “tcpdump -i vlan0.30 -n -vv '(udp port 546 or port 547) or icmp6'”
-i any is not working.

This is the result:

tcpdump: listening on vlan0.30, link-type EN10MB (Ethernet), capture size 262144 bytes
21:39:59.353468 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff69:d43f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::c5c:b6ff:fe69:d43f
     unknown option (14), length 8 (1):
       0x0000:  260d f991 3923
21:40:00.377453 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::c5c:b6ff:fe69:d43f > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
     source link-address option (1), length 8 (1): 0e:5c:b6:69:d4:3f
       0x0000:  0e5c b669 d43f
21:40:00.377710 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::2d0:b4ff:fe01:de3f > fe80::c5c:b6ff:fe69:d43f: [icmp6 sum ok] ICMP6, router advertisement, length 120
   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:xxxx:xxxx:5c00::/61, Flags [onlink, auto], valid time 86400s, pref. time 14400s
       0x0000:  3dc0 0001 5180 0000 3840 0000 0000 2a01
       0x0010:  xxxx xxxx 5c00 0000 0000 0000 0000
     rdnss option (25), length 24 (3):  lifetime 600s, addr: 2a01:xxxx:xxxx:5c03:2d0:b4ff:fe01:de3f
       0x0000:  0000 0000 0258 2a01 xxxx xxxx 5c03 02d0
       0x0010:  b4ff fe01 de3f
     dnssl option (31), length 32 (4):  lifetime 600s, domain(s): local.xxxx.net.
       0x0000:  0000 0000 0258 056c 6f63 616c 066d 6172
       0x0010:  6672 6903 6e65 7400 0000 0000 0000
     mtu option (5), length 8 (1):  1492
       0x0000:  0000 0000 05d4
     source link-address option (1), length 8 (1): 00:d0:b4:01:de:3f
       0x0000:  00d0 b401 de3f
21:40:01.378329 IP6 (flowlabel 0x6a0e8, hlim 1, next-header UDP (17) payload length: 92) fe80::c5c:b6ff:fe69:d43f.546 > ff02::1:2.547: [udp sum ok] dhcp6 confirm (xid=87028c (client-ID hwaddr/time type 1 time 695087396 0e5cb669d43f) (option-request DNS-server DNS-search-list Client-FQDN SNTP-servers) (elapsed-time 0) (IA_NA IAID:3060388927 T1:0 T2:0 (IA_ADDR 2a01:xxxx:xxxx:5c01::1c2e pltime:0 vltime:0)))
21:40:01.378562 IP6 (hlim 64, next-header UDP (17) payload length: 82) fe80::2d0:b4ff:fe01:de3f.547 > fe80::c5c:b6ff:fe69:d43f.546: [udp sum ok] dhcp6 reply (xid=87028c (client-ID hwaddr/time type 1 time 695087396 0e5cb669d43f) (server-ID hwaddr/time type 1 time 761521315 00d0b401de3f) (status-code Success))
21:40:01.817261 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff00:1c2e: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:xxxx:xxxx:5c01::1c2e
     unknown option (14), length 8 (1):
       0x0000:  e22c d804 8fac
21:40:05.810038 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::2d0:b4ff:fe01:de3f > fe80::c5c:b6ff:fe69:d43f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::c5c:b6ff:fe69:d43f
     source link-address option (1), length 8 (1): 00:d0:b4:01:de:3f
       0x0000:  00d0 b401 de3f
21:40:05.810398 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c5c:b6ff:fe69:d43f > fe80::2d0:b4ff:fe01:de3f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::c5c:b6ff:fe69:d43f, Flags [solicited]
21:40:10.969470 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::c5c:b6ff:fe69:d43f > fe80::2d0:b4ff:fe01:de3f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::2d0:b4ff:fe01:de3f
     source link-address option (1), length 8 (1): 0e:5c:b6:69:d4:3f
       0x0000:  0e5c b669 d43f
21:40:10.969513 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::2d0:b4ff:fe01:de3f > fe80::c5c:b6ff:fe69:d43f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::2d0:b4ff:fe01:de3f, Flags [router, solicited]
10 packets captured
197 packets received by filter
0 packets dropped by kernel

Running tcpdump on vlan0.110 (guest wifi) doesn’t received any packages.

And I noticed the IPv6 is from the GuestWIFI (VLAN 110) Range, but under ISC DHCPv6 –
Leases it gets shown as the “Client” Interface, is that because there share the same Ethernet-Port?
Also I noticed that the Link-Local Address of the OpnSense VLAN-Interfaces is all the same

[gigagames]

Ok, i fixed it.
on my WAN i set the IPv6 Prefix delegation to 59.
My provider gives me a /56.

In the /var/dhcp/etc/dhcpvd6.conf the 3 subnets were listet as /61.
After changing my WAN to /56 in the dhcpvd6.conf there got changed to /64
and my devices are getting 2 IPv6 from the correct VLAN
(2a01:xxxx:xxxx:a403::2000/128 and
inet6 2a01:xxxx:xxxx:a403:be24:11ff:fe02:e90e/64)
so there seems there is a bug in opnSense.


edit: Found this https://forum.opnsense.org/index.php?topic=17059.0
seems like the bug is already known

[meyergru]

I would not call that a bug. You configured the prefix size wrong and because of that, the prefix that resulted on one VLAN looked like what you expected from another.