On Wed, Aug 14, 2019 at 12:33:04PM +0200, Sebastien Marie wrote: > 10:52:43.021623 clyde.39234 > bert.22: P 1:37(36) ack 120 win 256 > <nop,nop,timestamp 144013579 2288520555> [class 0x48] [flowlabel 0x46f7a] > (len 68, hlim 64) > 10:52:43.022002 bert.22 > clyde.39234: P 120:164(44) ack 37 win 267 > <nop,nop,timestamp 2288522085 144013579> [class 0x48] [flowlabel 0x6d55f] > (len 76, hlim 64) > 10:52:43.022081 clyde.39234 > bert.22: R [tcp sum ok] 652718888:652718888(0) > win 0 (len 20, hlim 64)
So you see TCP resets that make no sense after some time of inactivity. In my experience this is a bridge(4) somewhere in the network running pf(4) with a default "block return" rule. The entries in the bridge MAC table timeout, the bridge sends a broadcast to all ports, this packet hits pf on an interface, where it is not expected. Then pf generates a TCP reset packet. Run tcpdump -e and check whether the MAC address of the reset matches clyde or bert. If not, you have the bad machine. bluhm
