From owner-freebsd-ipfw@freebsd.org Fri Dec 9 12:55:40 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE626C6AF4C for ; Fri, 9 Dec 2016 12:55:40 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C55716E1 for ; Fri, 9 Dec 2016 12:55:39 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1481288136; l=1166; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=GV6uxe1h4mYyKd4LPuLt7kUtEY9sGuLC+mDWproCFAU=; b=EjK6VXtr8dofAwz3UlFeeeViLiqjdw5WBXOvJvrl3HMrYm2pqhxzNQk2HfzNDZcOvH UXn9eWoU4viEmJCrg8KFRJ6ii3ttuZ43Zyi8L+jpElmc6Qvh606qzBqTzSSMHmpjYp4i S2Un5NCvuQ217zbDW8FkPBYPSqnZQbL6sM+LU= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0h99HjZzw= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b667.virtua.com.br [187.2.182.103]) by smtp.strato.de (RZmta 39.10 DYNA|AUTH) with ESMTPSA id c06d32sB9CtZMRb (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 9 Dec 2016 13:55:35 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id BC583746A1B1; Fri, 9 Dec 2016 10:18:26 -0200 (BRST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: IPFW problem with passing IPSEC through in-kernel NAT From: "Dr. Rolf Jansen" In-Reply-To: <005b34c8-2217-fa06-5584-6999022481a3@denninger.net> Date: Fri, 9 Dec 2016 10:18:26 -0200 Cc: Karl Denninger Content-Transfer-Encoding: quoted-printable Message-Id: <156E272C-0EFA-4A15-8544-C580AAEB6033@obsigna.com> References: <099203a1-f601-bb79-548d-27c62fcbf556@denninger.net> <005b34c8-2217-fa06-5584-6999022481a3@denninger.net> To: freebsd-ipfw@freebsd.org X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:55:40 -0000 > Am 09.12.2016 um 02:11 schrieb Karl Denninger : > ... > Some more information on this issue.... I suspect that something is > getting mangled somewhere in the IP stack, perhaps related to hardware > checksumming or similar -- or in the ipfw code. I had always ran into IPsec-NAT-UDP checksumming issues since I started = working with FreeBSD, that tim v8.0. With a rather simple change in the = respective kernel source file at least my issue can be resolved. This = may be related to your issue or even not, anyway, I guess it is worth to = give it a try. I am now running FreeBSD 11-RELEASE-p5. On line 462 of file = /usr/src/sys/netinet/udp_usrreq.c, I replaced: if (uh->uh_sum) { with: if (uh->uh_sum && uh->uh_dport !=3D htons(1701) && uh->uh_dport !=3D htons(4500)) { This effectively skips extended UDP checksumming for certain UDP ports = -- here the L2TP and IPsec-NAT-T ports. When I investigated the issue, I = found in one related RFC, that IPsec-NAT-T isn't supposed to do UDP = checksumming on the encapsulated packets anyway, and my patch enforces = this behaviour. Best regards Rolf=