From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 07:06:25 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65CEC106564A for ; Wed, 28 Jul 2010 07:06:25 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id D915B8FC13 for ; Wed, 28 Jul 2010 07:06:23 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6S76LQu014258 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 28 Jul 2010 09:06:21 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6S76LiO024394; Wed, 28 Jul 2010 09:06:21 +0200 (MEST) Date: Wed, 28 Jul 2010 09:06:21 +0200 From: Daniel Hartmeier To: Justin Message-ID: <20100728070621.GA11444@insomnia.benzedrine.cx> References: <4C4D7EED.4060704@sk1llz.net> <20100727074850.GB1114@insomnia.benzedrine.cx> <4C4F8D19.2020609@sk1llz.net> <4C4F94F8.5050709@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4F94F8.5050709@sk1llz.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: pf synproxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 07:06:25 -0000 On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote: > - tcpdumps showing the initial connect attempt (logs below were > furhter along the process); > > external: > 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], > proto TCP > (6), length 52) > REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0x537b (correct), se > q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], > length 0 > 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], > proto TCP > (6), length 44) > CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53782: Flags [S.], > cksum 0x7920 (correct), s > eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0 > 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], > proto TCP > (6), length 40) > REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [.], > cksum 0x95ec (correct), ac > k 3819585456, win 64240, length 0 > 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], > proto TCP > (6), length 40) The TCP handshake with the client makes sense. The client's SYN offers wscale and sack, pf's SYN+ACK has IP tos 0x10 and neither wscale nor sack, and win 0. > internal: > 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], > proto TCP > (6), length 52) > REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [S], > cksum 0x84ee (correct), se > q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], > length 0 This doesn't seem to be captured on the internal interface, at least it is not the server handshake replayed by pf's synproxy. Note the (random) client source port 53786 doesn't match 53782 of the external capture above. Instead, it looks like ANOTHER connection captured on the external interface. The SYN has IP tos 0x0 and offers wscale and sack, so this CANNOT be a packet generated by pf's synproxy... What we want to see is the two TCP handshakes related to the same client connection, once on the interface towards the client, once on the interface towards the server. The client source port is the same. Ideally, tcpdump on both interface, writing to two files with tcpdump -w. Reproduce the issue. Find out what client source port was used for that connection. Then tcpdump -r and extract all packets of that port (src or dst) in both files... And the pfctl -vvss output should contain the state with that port as well. There is precisely one external and one internal interface, and pf is the only connection between these two networks, right? If the client's SYN can somehow reach the server bypassing pf, the synproxy will not work, there'd be two handshakes to the server using different sequence numbers, the server would accept the first, ignore the other, confusion would ensue ;) Daniel