[Bug 292319] [network: fibs] traffic comes from the wrong fib in some cases.
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 10 Jan 2026 03:51:09 UTC
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.