Date: Tue, 12 Nov 2019 07:05:04 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235607] Incorrect checksums with NAT on vtnet with offloading Message-ID: <bug-235607-7501-JgmXuu2BZf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235607-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-235607-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235607 --- Comment #8 from Jorge Schrauwen <sjorge+signup@blackdot.be> --- Oops, I was pertty sure I did update this with the ipf results. But guess I= did not. I could not get ipf to work either, turns out it was similar to the native firewall on illumos (where I was running the bhyve instance). Turns out the illumos version of ipf also has the issue: https://smartos.org/bugview/OS-7924. Joyent who are doing the bhyve fork on illumos and did all the offloading w= ork are going to revert the change where loopback traffic (in the broader sense here that any traffic not hitting the mac of a physical interface, so inter guest traffic too) would not get checksummed soonish. As other software in bhyve guests and native zones is also not dealing properly with this. e.g. vpnservers like wireguard, openvpn,...=20 https://smartos.org/bugview/OS-8025 More details on the revert of this can be found here: https://smartos.org/bugview/OS-8027 So while it looks like ipf, ipfw, and pf do indeed not cope well with traff= ic that has blank checksums when all the offloading is enabled on the vtnet interface... it's certainly not the only code that has issues with it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235607-7501-JgmXuu2BZf>