[Bug 296944] sys/netpfil/common/rdr:ipfnat_local_redirect test failing in CI

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296944

--- Comment #7 from Michael Tuexen <tuexen@freebsd.org> ---
I think the problem is a bug in the checksum handling when doing redirections.

Here is how I can reproduce the issue:
I use two systems: one runs ipfilter and owns 192.168.1.140 and one is a target
which own 192.168.1.175.

On 192.168.1.140 I have a file ipfnat.rule with the contents

rdr '*' from any to 192.168.1.140/24 port = 1234 -> 192.168.1.175 port 4321 tcp


an then run as root
kldload ipfilter
sysctl net.inet.ip.forwarding=1
ipf -E
ipnat -CF -f ipfnat.rule
pfilctl link -o ipfilter:default-ip4 inet-local

When I then run

nc 192.168.1.140 1234

on the machine owning 192.168.1.140 I can observe on the machine owning
192.168.1.175:

tuexen@fb13:~ % tcpdump -v -n tcp and not port 22
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length
262144 bytes
10:02:04.961239 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6),
length 60)
    192.168.1.140.31650 > 192.168.1.175.4321: Flags [S], cksum 0x19d6
(incorrect -> 0x0d81), seq 3625275702, win 65535, options [mss 16344,nop,wscale
8,sackOK,TS val 196065871 ecr 0], length 0
10:02:05.912539 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6),
length 60)
    192.168.1.140.31650 > 192.168.1.175.4321: Flags [S], cksum 0x15e1
(incorrect -> 0x098c), seq 3625275702, win 65535, options [mss 16344,nop,wscale
8,sackOK,TS val 196066884 ecr 0], length 0
10:02:08.198916 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6),
length 60)
    192.168.1.140.31650 > 192.168.1.175.4321: Flags [S], cksum 0x0cf4
(incorrect -> 0x009f), seq 3625275702, win 65535, options [mss 16344,nop,wscale
8,sackOK,TS val 196069169 ecr 0], length 0

So the checksum is wrong. This did not matter in the test case used in the CI
when using the loopback interface, since the loopback interface was just
marking the checksum as being checked and correct. With the recent change this
is not the case anymore and the bug in ipfilter was uncovered.

-- 
You are receiving this mail because:
You are on the CC list for the bug.