From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 19 08:47:16 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52675106566C for ; Mon, 19 Jul 2010 08:47:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC9D8FC19 for ; Mon, 19 Jul 2010 08:47:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o6J8lBRU005975; Mon, 19 Jul 2010 18:47:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 19 Jul 2010 18:47:11 +1000 (EST) From: Ian Smith To: Mamontov Roman In-Reply-To: <893037983.20100719092644@gmail.com> Message-ID: <20100719181208.A86988@sola.nimnet.asn.au> References: <1931583025.20100715114512@gmail.com> <20100715183743.S86988@sola.nimnet.asn.au> <893037983.20100719092644@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org Subject: Re: Problem with ipfw nat and packet to local services X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 08:47:16 -0000 On Mon, 19 Jul 2010, Mamontov Roman wrote: > Hello, Ian. > > > UDP port 33564 on this box (xxx.xxx.xxx.xxx) is not redirected to any > > other address:port, and you have specified deny_in (-deny_incoming in > > natd-speak) so, well, you got what you asked for .. > > > See the description under -deny_incoming and the explanation of what > > happens to incoming packets under -alias_address in natd(8) .. the nat > > description in ipfw(8) is still a bit thin, so natd(8) is still useful. > > > Without deny_in, new inbound packets should be passed to the local > > machine - so you will then need firewall rules to restrict which local > > ports are to be accessible for connections from the outside. > > > cheers, Ian > > I remove option deny_in from nat configuration. But inbound packets not passed to the > local services. > > #ipfw nat show config > ipfw nat 1 config ip xxx.xxx.xxx.xxx > > #ipfw show > 00035 59 4703 nat 1 log ip from any to any via ext_if1 > 65000 510 44734 allow ip from any to any > 65535 58083 11212917 deny ip from any to any Hi Mamontov, What's the value of sysctl net.inet.ip.fw.one_pass ? It needs to be 0 so that packets will re-enter the firewall after NAT processing. Otherwise, it might help to a) run 'ipfw zero' before any tests .. I'm wondering about all those packets hitting rule 65535; were they from before adding rule 65000? b) add some count rules before and after nat, to show all packets that may be eligible for NAT translation, maybe something like: 00020 count log ip from any to any in recv ${ext_if} 00022 count log ip from any to any out xmit ${ext_if} 00024 count log ip from any to any out recv ${int_if} xmit ${ext_if} 00035 nat ... 00040 count log ip from any to any in recv ${ext_if} 00042 count log ip from any to any out xmit ${ext_if} 00044 count log ip from any to any out recv ${int_if} xmit ${ext_if} So you actually get to see the flow of packets before and after nat, both to/from the local box and packets mapped to/rom inside addresses. Again, an 'ipfw zero' before tests will make packet counts clearer. Of course something like '# tcpdump -pn -i ext_if' will also show all packets via ext_if in some detail. Be more specific if just looking for some particular flows, like maybe appending 'udp port NNNNN' to that. That is, try to follow packets you'd expect to be coming in for services on the local box so if they are disappearing, you'll know where or why. 'netstat -finet -an' will show all those services that are listening. If that doesn't help, we'll need more information. cheers, Ian