Am Fri, 10 Jan 2020 08:49:27 +0100 schrieb Janne Johansson <[email protected]>:
Hi, thanks for your help. Looking at the tcpdump on both sides. I seems to be way you described. Though it appears to me that looking at a dump that a packet is received on enc0 with a destination that is located on behinde another interface (not enc0). But instead of routing the packet to it's final destination instead the packet is returned to the sender. Somehow the packet is instantanously reflected back to machine A. It is not being routed. And yes routing is enabled via sysctl net.inet.ip.forwarding. Command issued: nc -nvv <ip-host-in-subnet-of-b> 22 Here the dump I am talking about: $ tcpdump -envps 1500 -i enc0 -l tcpdump: listening on enc0, link-type ENC 10:50:45.277092 (authentic,confidential): SPI 0x15c705ad: <ip-server-a> > <ip-server-b>: 10.0.4.2.9021 > <ip-host-in-subnet-of-b>: S [tcp sum > ok] 372562307:372562307(0) win 16384 <mss > 65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3289626089 0> > (DF) (ttl 64, id 14140, len 64) (DF) (ttl 64, id 55846, len 84) > 10:50:45.277113 (authentic,confidential): SPI 0x4b2d81a9: > <ip-server-a> > <ip-server-a>: 10.0.4.2.9021 > > <ip-host-in-subnet-of-b>.22: S [tcp sum ok] 372562307:372562307(0) > win 16384 <mss 65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp > 3289626089 0> (DF) (ttl 63, id 14140, len 64) (DF) (ttl 64, id 29687, > len 84, bad ip cksum 0! -> 4011) As mentioned in the previous Mail the IP 10.0.4.2 is the IP-address of the enc0 of server A. Thank you for your time. Best regards, Stephan > > > > [18:45:09.393548 (authentic,confidential): SPI 0xf0ded495: > > 185.165.169.74 > > > 188.194.145.145: 10.0.4.2.15461 > 10.0.1.50.10025: S [tcp sum ok] > > > > > 942633060:942633060(0) win 16384 <mss > > 65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 97396526 0> > > (DF) (ttl 64, id 49904, len 64) (ttl 52, id 19763, len 84) > > 18:45:09.393583 (authentic,confidential): SPI 0x9aa6e013: > > 188.194.145.145 > > > 185.165.169.74: 10.0.4.2.15461 > 10.0.1.50.10025: S [tcp sum ok] > > 942633060:942633060(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale > > 6,nop,nop,timestamp 97396526 0> (ttl 63, id 51282, len 64) (ttl 64, > > id 2434, len 84, bad ip cksum 0! -> bfe0) > > > > Isn't "0" for checksum a typical sign of "the outgoing IP queue did > not run checksum in software because the network driver has > hardware-offloading for it" and tcpdump can never see that? > See if you can grab the same packet from both sides and see if it's > correct when it arrives. >
