[Bug 280648] Traffic leak between fibs

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 06 Aug 2024 09:27:25 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280648

            Bug ID: 280648
           Summary: Traffic leak between fibs
           Product: Base System
           Version: 14.1-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: banezmesm@gmail.com

Hello everyone. I met a problem with my Freebsd configuration. I used two fibs
fib0 for management and fib1 for traffic routing. When i tried to connect to my
freebsd my ssh session was closed by timeout. This session passed fib1 then it
passed a switch and then this traffic came to mgmt interface in fib0.
1718370615708.png
I checked pflog and found out that SYN was passed but SYN-ACK was blocked.

10:40:14.738757 rule 50/0(match): pass in on lagg0.3100: 192.168.1.10.39324 >
192.168.2.20.22: Flags [S , seq 3192491261, win 64240, options [mss 1460,
[|tcp]
10:40:14.738823 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
10:40:15.760558 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
10:40:16.785316 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
10:40:17.776546 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
10:40:18.775315 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
10:40:20.391522 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
10:40:21.418648 rule 1/0(match): block in on lagg0.3101: 192.168.2.20.22 >
192.168.1.10.39324: Flags [S.], seq 3872911900, ack 3192491262, win 65535,
options [mss 1460, [|tcp]
Click to expand...


Then i checked mgmt interface with tcpdump and there wasn't incoming traffic.
The SYN packed was lost.

admin@mypc:~ $ sudo tcpdump -nli mgmt host 192.168.2.20 and port 22 and host
192.168.1.10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on mgmt, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:45:04.378916 IP 192.168.2.20.22 > 192.168.1.10.57788: Flags [S.], seq
1690518431, ack 2823437748, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 800362632 ecr 2768737784], length 0
10:45:05.382466 IP 192.168.2.20.22 > 192.168.1.10.57788: Flags [S.], seq
1690518431, ack 2823437748, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 800363638 ecr 2768737784], length 0
10:45:05.392406 IP 192.168.2.20.22 > 192.168.1.10.57788: Flags [S.], seq
1690518431, ack 2823437748, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 800363651 ecr 2768738798], length 0
10:45:06.390812 IP 192.168.2.20.22 > 192.168.1.10.57788: Flags [S.], seq
1690518431, ack 2823437748, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 800364642 ecr 2768738798], length 0
10:45:07.408389 IP 192.168.2.20.22 > 192.168.1.10.57788: Flags [S.], seq
1690518431, ack 2823437748, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 800365665 ecr 2768740814], length 0
10:45:08.425344 IP 192.168.2.20.22 > 192.168.1.10.57788: Flags [S.], seq
1690518431, ack 2823437748, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 800366684 ecr 2768740814], length 0
Click to expand...
I checked interface out and there wasn't any SYN packet too.
admin@mypc:~ $ sudo tcpdump -nli lagg0.3101 host 192.168.2.20 and port 22 and
host 192.168.1.10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lagg0.3101, link-type EN10MB (Ethernet), snapshot length 262144
bytes
12:06:11.070143 IP 192.168.2.20.22 > 192.168.1.10.54686: Flags [S.], seq
3117832771, ack 2273301168, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 3221841358 ecr 2773605130], length 0
12:06:12.073943 IP 192.168.2.20.22 > 192.168.1.10.54686: Flags [S.], seq
3117832771, ack 2273301168, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 3221842359 ecr 2773606134], length 0
12:06:13.110800 IP 192.168.2.20.22 > 192.168.1.10.54686: Flags [S.], seq
3117832771, ack 2273301168, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 3221843399 ecr 2773606134], length 0
12:06:14.090184 IP 192.168.2.20.22 > 192.168.1.10.54686: Flags [S.], seq
3117832771, ack 2273301168, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS
val 3221844378 ecr 2773608150], length 0
Click to expand...It looked like route leaking and i checked routing table but
i didn't find any problem there.

admin@mypc:~ $ sudo netstat -rn | grep 192.168.2
default 192.168.2.1 UGS mgmt
192.168.2.0/26 link#1 U mgmt
192.168.2.20 link#3 UHS lo0
admin@mypc:~ $ sudo setfib 1 netstat -rn | grep 192.168.2
192.168.2.0/24 10.222.253.101 UG1 lagg0.3101
192.168.2.0/24 10.222.253.102 UG1 lagg0.3101

My pf.conf

# Port macros
NET_MGMT = "192.168.2.0/26"
JH_NOC = "192.168.1.10"

# Tables
table <DST_JH_NOC_TO_NET_MGMT> { $NET_MGMT }
table <SRC_NET_MGMT_TO_JH_NOC> { $JH_NOC }

# Config
set skip on lo0
set skip on mgmt
set skip on vtnet1
set skip on pfsync0
set limit states 6000000
set limit src-nodes 6000000

# Scrub
scrub in all

# Firewall policy
pass out all
block in log all rtable 1
pass in log quick proto icmp rtable 1
pass in log quick proto { tcp, udp } from <SRC_JH_NOC_TO_NET_MGMT> to
<DST_JH_NOC_TO_NET_MGMT> rtable 1
pass in log quick proto { tcp, udp } from <DST_JH_NOC_TO_NET_MGMT> to
<SRC_JH_NOC_TO_NET_MGMT> rtable 1
Click to expand...

I supposed that traffic somehow leaked from fib1 to fib0. Please help me to fix
it

-- 
You are receiving this mail because:
You are the assignee for the bug.