From owner-freebsd-pf@FreeBSD.ORG Thu Jul 28 09:37:49 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C12E616A41F for ; Thu, 28 Jul 2005 09:37:49 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C24D43D5F for ; Thu, 28 Jul 2005 09:37:46 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id j6S9bdkr008536 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2005 11:37:39 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id j6S9bdJi020351; Thu, 28 Jul 2005 11:37:39 +0200 (MEST) Date: Thu, 28 Jul 2005 11:37:38 +0200 From: Daniel Hartmeier To: Marcel Braak Message-ID: <20050728093738.GH15154@insomnia.benzedrine.cx> References: <31BA35C490DBFC40B5C331C7987835AE61236C@mbafmail.internal.mba-cpa.com> <42E88BEC.4060007@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42E88BEC.4060007@xs4all.nl> User-Agent: Mutt/1.5.6i Cc: "Melameth, Daniel D." , pf@benzedrine.cx, freebsd-pf@freebsd.org Subject: Re: pinging same host on the internet from two different LAN stations 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: Thu, 28 Jul 2005 09:37:50 -0000 On Thu, Jul 28, 2005 at 09:40:28AM +0200, Marcel Braak wrote: > Before i had a linux/iptables firewall box that doesn't have this problem. > I hope there's a fix for PF cause i think this is a very anoying issue. You'll have to find out and explain to me how any other product dispatches incoming ping replies (ICMP echo reply) to the appropriate client, in this case. I'm assuming you're using a single NAT replacement address (and not a pool of several of them), and that the other product was working in that same configuration (you can't expect pf to work with a single address just because iptables did with a pool, for instance, that's comparing apples and oranges). When two clients (let's call them 10.1.1.2 and 10.1.1.3) ping the same external host at the same time, the NAT device will translate both source addresses to its own (single) external address (say 87.76.7.79). Then the external peer (say 199.185.137.3) sends replies to both, which look like # tcpdump -s 1600 -nvvvpX icmp 199.185.137.3 > 87.76.7.79: icmp: echo reply (id:4466 seq:2) (ttl 233, id 48582, len 84) 0000: 4500 0054 bdc6 0000 e901 648a c7b9 8903 E..T½Æ..é.d.ǹ.. 0010: 574c 074f 0000 af3b 4466 0002 42e8 a4c6 WL.O..¯;Df..Bè¤Æ 0020: 0007 39a3 0809 0a0b 0c0d 0e0f 1011 1213 ..9£............ 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 ............ !"# 0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0050: 3435 3637 4567 199.185.137.3 > 87.76.7.79: icmp: echo reply (id:7816 seq:1) (ttl 233, id 25729, len 84) 0000: 4500 0054 6481 0000 e901 bdcf c7b9 8903 E..Td...é.½Ïǹ.. 0010: 574c 074f 0000 af87 7816 0001 42e8 a511 WL.O..¯.x...Bè¥. 0020: 0004 0560 0809 0a0b 0c0d 0e0f 1011 1213 ...`............ 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 ............ !"# 0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0050: 3435 3637 4567 pf must decide, for each incoming reply, whether to send it to 10.1.1.2 or 10.1.1.3. There's nothing on IP level (no IP header field) that would help make that decisions, both kinds of replies are equal on IP level. So, we peek into the ICMP header fields to find something which helps us associate replies with outgoing queries ("sessions", "connections"). The ICMP id (4466 and 7816 in the examples above) is a good candidate, as most ping tools will pick a random id per invokation. Assuming Windows ping is not doing that, you'll have to provide an alternative way to decide which client to send replies to. There's ICMP sequence numbers, but they can and will overlap for concurrent ping invokations. The ICMP echo reply quotes the ICMP payload of the query. But most ping tools will use a constant payload, so that's no distinguishing criterion. The NAT device could tamper with the payload and insert its own ID there, but that's modifying the packet in an intrusive and unexpected way. I'm curious how any NAT device would do that correctly without relying on unique/random ICMP ids. You claim some do, you'll have to provide the evidence and explanation, if you want me to do the same in pf :) Daniel