Project

General

Profile

Actions

Bug #15693

open

Bug #13423 still present in 24.03-RELEASE version

Added by Marek Hajduczenia 3 months ago. Updated about 2 months ago.

Status:
Incomplete
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
24.03
Affected Architecture:
amd64

Description

Bug #13423 seems to be still present in 24.03-RELEASE version.

I have a fixed IPv6 assigned interface on a VM (fdaa:bbcc:ddee:150::4)

2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:7c:4e:47 brd ff:ff:ff:ff:ff:ff
inet 192.168.150.4/24 brd 192.168.150.255 scope global enp6s18
valid_lft forever preferred_lft forever
inet6 fdaa:bbcc:ddee:150::4/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe7c:4e47/64 scope link

which can hit all other IPv6-addressed VMs on the very same VLAN

ping6 fdaa:bbcc:ddee:150::3
PING fdaa:bbcc:ddee:150::3(fdaa:bbcc:ddee:150::3) 56 data bytes
64 bytes from fdaa:bbcc:ddee:150::3: icmp_seq=1 ttl=64 time=0.657 ms
64 bytes from fdaa:bbcc:ddee:150::3: icmp_seq=2 ttl=64 time=0.759 ms
64 bytes from fdaa:bbcc:ddee:150::3: icmp_seq=3 ttl=64 time=0.643 ms
^C
--- fdaa:bbcc:ddee:150::3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2055ms
rtt min/avg/max/mdev = 0.643/0.686/0.759/0.051 ms

When trying to hit the ::1 (gateway on pfSense side), I am getting no love

ping6 fdaa:bbcc:ddee:150::1
PING fdaa:bbcc:ddee:150::1(fdaa:bbcc:ddee:150::1) 56 data bytes
From fdaa:bbcc:ddee:150::4 icmp_seq=1 Destination unreachable: Address unreachable
From fdaa:bbcc:ddee:150::4 icmp_seq=2 Destination unreachable: Address unreachable
From fdaa:bbcc:ddee:150::4 icmp_seq=3 Destination unreachable: Address unreachable
^C
--- fdaa:bbcc:ddee:150::1 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3072ms

The routing table is missing link local of the gateway from pfSense

route -n6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: U 256 1 0 lo
fdaa:bbcc:ddee:150::/64 :: U 256 3 0 enp6s18
fe80::/64 :: U 256 2 0 enp6s18
::/0 fdaa:bbcc:ddee:150::1 UG 1024 1 0 enp6s18
::1/128 :: Un 0 4 0 lo
fdaa:bbcc:ddee:150::4/128 :: Un 0 4 0 enp6s18
fe80::5054:ff:fe7c:4e47/128 :: Un 0 4 0 enp6s18
ff00::/8 :: U 256 5 0 enp6s18
::/0 :: !n -1 1 0 lo

and capture (/usr/sbin/tcpdump -ni lagg0.150 -c '1000' -U -w - '((ip6)) and ((not vlan))') off pfSense shows failed neighbor solicitation, matching precisely the bug in question

18:03:23.505431 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:24.509708 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:24.588257 IP6 fe80::280:eaff:fe9e:38e6.546 > ff02::1:2.547: UDP, length 40
18:03:25.533726 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:26.557767 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:27.581686 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:27.640761 IP6 fe80::ca43:2694:ff9e:5ec3.50540 > ff02::c.1900: UDP, length 343
18:03:28.605633 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:29.629864 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:30.653670 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32
18:03:31.677629 IP6 fdaa:bbcc:ddee:150::4 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fdaa:bbcc:ddee:150::1, length 32

I am still looking for a workaround, but it does not seem to exist. I tested all RA options on the interface, but it does not seem to change anything. Since it works VM-2-VM on the same subnet, I am inclined to blame whatever is going on internally. I am happy to share details of he pfSense config, if that helps with the T/S


Files

Capture006.PNG (98.3 KB) Capture006.PNG pfSense capture config Marek Hajduczenia, 08/27/2024 12:02 AM
Actions #1

Updated by Kristof Provost 3 months ago

The best way to confirm that this is indeed the same bug would be to gather `ifmcstat -i <ifname>` on the pfsense box. Please also include the status file from <pfsense ip>/status.php.

Actions #2

Updated by Kris Phillips about 2 months ago

  • Status changed from New to Incomplete

Marking as Incomplete until we have that information.

Actions

Also available in: Atom PDF