On Wed, Dec 29, 2010 at 10:40:58AM +0000, Stuart Henderson wrote: > On 2010/12/29 08:51, Johan Helsingius wrote: > > Running pf on openbsd 4.8 (i386), I find something very strange going on. > > Looking at the log: > > > > Dec 28 22:23:37.772604 rule 4/(match) [uid 0, pid 28161] pass in on xl2: > > xxx.yyy.zzz.aaa.51717 > foo.bar.www: S [tcp sum ok] > > 3754046362:3754046362(0) win 4095 <mss 1200> (DF) (ttl 64, id 23285, len 44) > > Dec 28 22:23:37.772690 rule 17/(match) [uid 0, pid 28161] pass out on rl0: > > xxx.yyy.zzz.aaa.51717 > foo.bar.www: S [tcp sum ok] > > 3754046362:3754046362(0) win 4095 <mss 1200> (DF) (ttl 63, id 23285, len > > 44, bad > > cksum 7c0b! differs by 100) > > > > So the packet is OK going into the firewall, but has a bad checksum going > > out? > > > > Julf > > > > > > You are probably offloading checksums to the NIC hardware. If so, > it is normal that tcpdump does this. This is because of delayed checksum calculation in ip_output. Between the two pf_test() calls ip_forward() decrements the TTL but does not fix the cksum. pf log call on outbound rules will almost always report bad checksums, ip_output() will calculate the checksum a bit later unless HW support is available.
-- :wq Claudio
