From owner-freebsd-net@freebsd.org Fri Jan 20 21:07:12 2017 Return-Path: Delivered-To: freebsd-net@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 A946DCB9B6A for ; Fri, 20 Jan 2017 21:07:12 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73FFD1361; Fri, 20 Jan 2017 21:07:12 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8ripyyfi1726l7ds8ua.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:4883:fabf:4b8b:94c2]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id A6BB1358DF; Fri, 20 Jan 2017 22:07:10 +0100 (CET) From: "Kristof Provost" To: "Bakul Shah" Cc: "Alan Somers" , "FreeBSD Net" Subject: Re: pf & NAT issue Date: Fri, 20 Jan 2017 22:07:10 +0100 Message-ID: <8146C6B6-3EA6-41A2-9FC7-0304E2128AFF@FreeBSD.org> In-Reply-To: <20170120205933.8948A124AEA3@mail.bitblocks.com> References: <20170120083555.ACCF9124AEA4@mail.bitblocks.com> <7C29D00C-94C0-4550-B1B2-CE307482B544@FreeBSD.org> <20170120203106.CD2C8124AEA4@mail.bitblocks.com> <20170120205933.8948A124AEA3@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6072) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 21:07:12 -0000 On 20 Jan 2017, at 21:59, Bakul Shah wrote: > On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost" > wrote: >> On 20 Jan 2017, at 21:31, Bakul Shah wrote: >>>> 11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags >>>> [P.], >>>> seq 1:10, ack 55, win 1026, options [nop,nop,TS val 198426 ecr >>>> 1468113725], length 9 >>> < 11:56:28.168712 IP 173.228.5.8.52015 > 149.20.1.200.21: Flags >>> [P.], >>> seq 3080825147:3080825156, ack 3912707414, win 1026, options >>> [nop,nop,TS val 198426 ecr 1468113725], length 9 >>> >>> Right here we see the problem. NAT mapping for the >>> port changed from 63716 to 52015. >>> >> Changing source ports is an entirely normal NAT behaviour. >> >> The best explanation is this: imagine that you have two clients A and >> B, >> both connect to X on port 80 via the NAT gateway G. >> Both use port 1000 as their source port. >> A connects, and the gateway maps A:1000 -> X:80 to G:1000 -> X:80. >> B connects, and now the gateway has to map B:1000 -> X:80 onto G:1000 >> -> >> X:80, but then it wouldn't be able to tell the two connections apart. >> That't can remap it onto G:1001 -> X:80 instead. > > It is the same connection! As a tcp connection is identified > by , If the port number > changes on the same connection, the remote side would see this > as a separate connection. Wait, it changes it within the same connection? I was reading it as a different connection, in which case that’d be quite ok. It’s of course not OK within one connection lifetime. I have no idea how that could be happening. Just in case, have you ever done a memtest on that box? Regards, Kristof