Date: Sat, 10 Jan 2026 03:51:09 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 292319] [network: fibs] traffic comes from the wrong fib in some cases. Message-ID: <bug-292319-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292319 Bug ID: 292319 Summary: [network: fibs] traffic comes from the wrong fib in some cases. Product: Base System Version: 15.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: william@firstyear.id.au On a FreeBSD 15.0-RELEASE machine with 2 fibs, traffic can "jump" between FIBS. Configuration: FIB: 1 OpenVPN: tun5 Ethernet: vtnet1 FIB: 5 Ethernet: vtnet5 vtnet1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=880028<VLAN_MTU,JUMBO_MTU,LINKSTATE,HWSTATS> ether 58:9c:fc:0a:57:56 inet 172.24.17.24 netmask 0xffffff00 broadcast 172.24.17.255 inet6 fe80::5a9c:fcff:fe0a:5756%vtnet1 prefixlen 64 scopeid 0x2 inet6 2403:580b:7d88:17::224 prefixlen 64 fib: 1 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vtnet5: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=880028<VLAN_MTU,JUMBO_MTU,LINKSTATE,HWSTATS> ether 58:9c:fc:0a:57:5a inet 172.24.17.26 netmask 0xffffff00 broadcast 172.24.17.255 inet6 fe80::5a9c:fcff:fe0a:575a%vtnet5 prefixlen 64 scopeid 0x6 inet6 2403:580b:7d88:17::226 prefixlen 64 fib: 5 media: Ethernet autoselect (10Gbase-T <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> tun5: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4080000<LINKSTATE,MEXTPG> inet 10.149.242.42 --> 10.149.242.41 netmask 0xffffffff inet6 2a07:de40:b2bf:2b::1089 prefixlen 64 inet6 fe80::5a9c:fcff:fe0a:5755%tun5 prefixlen 64 scopeid 0xb groups: tun fib: 1 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 66594 The intent is that when traffic from vtnet5 is emitted, it should be sent to the default router 172.24.17.1. This then directs the traffic back to vtnet1, and via tun5. When pinging from fib 5 to fib 1: # setfib -F5 ping 172.24.17.24 PING 172.24.17.24 (172.24.17.24): 56 data bytes 64 bytes from 172.24.17.24: icmp_seq=0 ttl=64 time=0.251 ms 64 bytes from 172.24.17.24: icmp_seq=1 ttl=64 time=0.260 ms 64 bytes from 172.24.17.24: icmp_seq=2 ttl=64 time=0.280 ms There is no packet loss, so the connection is stable and correct, and the external router functioning as intended. Testing this to a machine behind the vpn shows: # setfib -F5 ping 10.144.53.53 PING 10.144.53.53 (10.144.53.53): 56 data bytes 64 bytes from 10.144.53.53: icmp_seq=0 ttl=62 time=297.908 ms ^C --- 10.144.53.53 ping statistics --- 8 packets transmitted, 1 packets received, 87.5% packet loss round-trip min/avg/max/stddev = 297.908/297.908/297.908/0.000 ms In otherwords, the traffic is flowing from vtnet5 -> router -> vtnet1 -> tun5 and then reverse. Tcpdump on the router shows a peculiar behaviour. 13:28:08.139352 IP 172.24.17.26 > 10.144.53.53: ICMP echo request, id 7657, seq 0, length 64 13:28:08.139450 IP 172.24.17.26 > 10.144.53.53: ICMP echo request, id 7657, seq 0, length 64 13:28:09.167377 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 1, length 64 13:28:09.167420 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 1, length 64 13:28:10.183853 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 2, length 64 13:28:10.183915 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 2, length 64 13:28:11.201704 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 3, length 64 13:28:11.201730 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 3, length 64 13:28:12.230749 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 4, length 64 13:28:12.230792 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968, seq 4, length 64 The *first* ping comes from the correct IP (vtnet5: 172.24.17.26), but subsequent requests come from the IP of tun5 (tun5: 10.149.242.42) Similar, the tcpdump from the FreeBSD machine: # tcpdump -n -i vtnet5 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on vtnet5, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:41:41.340573 IP 172.24.17.26 > 10.149.242.42: ICMP echo request, id 31297, seq 0, length 64 13:41:41.340851 IP 10.149.242.42 > 172.24.17.26: ICMP echo reply, id 31297, seq 0, length 64 13:41:42.367165 IP 172.24.17.26 > 10.149.242.42: ICMP echo request, id 31297, seq 1, length 64 13:41:42.367387 IP 172.24.17.1 > 172.24.17.26: ICMP redirect 10.149.242.42 to host 172.24.17.24, length 92 13:41:42.367491 IP 10.149.242.42 > 172.24.17.26: ICMP echo reply, id 31297, seq 1, length 64 13:41:43.442201 IP 172.24.17.26 > 10.149.242.42: ICMP echo request, id 31297, seq 2, length 64 13:41:43.442440 IP 172.24.17.1 > 172.24.17.26: ICMP redirect 10.149.242.42 to host 172.24.17.24, length 92 13:41:43.442557 IP 10.149.242.42 > 172.24.17.26: ICMP echo reply, id 31297, seq 2, length 64 It seems to be an odd interaction with ICMP redirects, where these end up confusing the FreeBSD routing stack. The pings begin to come from 10.149.242.42, but they are still emitting from vtnet5 and sent to the router. The router then of course, drops the traffic for coming from an invalid ip range. Setting icmp_drop_redirect="YES" prevents this issue. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-292319-227>