From owner-freebsd-ipfw@freebsd.org Tue Jun 30 19:23:26 2015 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 CE3EC9900B9 for ; Tue, 30 Jun 2015 19:23:26 +0000 (UTC) (envelope-from g_amanakis@yahoo.com) Received: from nm15-vm6.bullet.mail.ne1.yahoo.com (nm15-vm6.bullet.mail.ne1.yahoo.com [98.138.91.108]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97E5E1626 for ; Tue, 30 Jun 2015 19:23:26 +0000 (UTC) (envelope-from g_amanakis@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435692045; bh=zhrTBYNrOOs5T5qrpbEVddvzvwEsWbrw7yOPZ+yOafg=; h=Subject:From:To:Date:From:Subject; b=cFoH63yExa1f1k9RQCUWXTULWMYVPhE1FOK+CFb9vJLDpz1IcoCPMkP25mpl/06FBQz4akdwATSkLMdA3A/0O6s2gy4FdIz8hWCg0H90cGXZop/5ALO1pYdAzvMCwmDfJEGcsqI4AJZPFqpEeAqe9Sdo07Rz/SdBUoh0M+G2+hkTaVGIY3QOe7tF8WpZIDnZsOwUr3CELOcIa4JVnldhmAoF7haB/rr8zUAWQUIlA8Rny8miGp6JfB31tzSwdfqtUzhGQm8LakPJ2e/3IKPDZKvRVc8EnzilHsBFOC/Fd28Z+64soeNxPZ2tkze3pYZrXqgIUVEHChViEckXivzSaA== Received: from [98.138.100.117] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jun 2015 19:20:45 -0000 Received: from [98.138.226.63] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jun 2015 19:20:42 -0000 Received: from [127.0.0.1] by smtp214.mail.ne1.yahoo.com with NNFMP; 30 Jun 2015 19:20:42 -0000 X-Yahoo-Newman-Id: 56117.10240.bm@smtp214.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: TuBS91EVM1mEQUQNnUce4w4d8u1FFE9P0iLkDDQf0NGA9sC pXzm5PioGHp8mku3Og0KJneslUaL01TSfiP8XKM8n3WI0S_0PhFJxM.Bok8d MdL44orSW_EPU7faZHu..eQbqhksH89.5DUn_RBAP5amfTJmYiUzLm2N94VW HY2KyoJAhpCzhRWHfDU70c9nm21sSdLb8DoesgCzTDBMBtqcwBakcJXKJKb9 Dqy9ZwguHObzaIwPHisxJVJkC.zNiT7dzZmLeXikEyQ35ijYA2r8t14MHzYw kfsKpoGhsLpk5c9MmegDfrYabwa67iltRbM2rwf7YuKWKd8XEpSfZAgmuI5l LVBmI1GU7cOE4iG_MHp7Az3C7rcxjaRuBZTc4ZkldOIsF6u9Yf16hq7KrN1m gCURzrcxnK1j2Ovs379k9EeorZLemAzfEnC1tyYMRjvJqVQpko8gZtvYqWTM JctEiMellBhWX4CD4ngHdlFNDwd5.G__IHZE5rMZ59jC1wSRl0z9SVRmcaPr LJYPAF_VX9JLHfnQSW.RXvNqgSslObR78Bw-- X-Yahoo-SMTP: 6sUo5IiswBDB2TZm6JKJ6DaI.Rsz4O0- Message-ID: <1435692039.18121.12.camel@yahoo.com> Subject: keep-state and in-kernel NAT exposes local ip on external interface From: Georgios Amanakis To: freebsd-ipfw@freebsd.org Date: Tue, 30 Jun 2015 21:20:39 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:23:26 -0000 On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I can fish (tcpdump)packets on em0 which have escaped the in-kernel NAT and have as source address an IP on the LAN. This should not happen and I can confirm that with pf this is not the case. I have the following ipfw rules: nat: ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset 00100 reass ip from any to any in 00200 allow ip from any to any via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip from any to any in recv em0 00500 check-state 00600 skipto 24000 ip from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0 keep-state 00800 deny log ip from any to any 24000 nat 123 ip from any to any out xmit em0 24100 allow ip from any to any Contrary to many online tutorials, including the example of the handbook regarding NAT ( https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when one places the NAT rules with the opposite order (i.e. outbound rule first and then the inbound rule) the problem disappears. i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000 nat 123 ip from any to any in recv em0 ... Why is this happening? Any objections to reversing the order of the NAT rules? From owner-freebsd-ipfw@freebsd.org Wed Jul 1 19:03:04 2015 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 65794991618 for ; Wed, 1 Jul 2015 19:03:04 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4DB1E3F for ; Wed, 1 Jul 2015 19:03:04 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 95BE91442 for ; Wed, 1 Jul 2015 22:02:55 +0300 (MSK) Message-ID: <5594395D.6050103@FreeBSD.org> Date: Wed, 01 Jul 2015 22:02:53 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface References: <1435692039.18121.12.camel@yahoo.com> In-Reply-To: <1435692039.18121.12.camel@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:03:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote: It is good example for my changes :) All this "skipto / keep-state" magic is not understandable. > On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I > can fish (tcpdump)packets on em0 which have escaped the in-kernel > NAT and have as source address an IP on the LAN. > > This should not happen and I can confirm that with pf this is not > the case. I have the following ipfw rules: > > nat: ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset > > 00100 reass ip from any to any in 00200 allow ip from any to any > via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip > from any to any in recv em0 00500 check-state 00600 skipto 24000 ip > from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv > em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0 > keep-state 00800 deny log ip from any to any 24000 nat 123 ip from > any to any out xmit em0 24100 allow ip from any to any > > Contrary to many online tutorials, including the example of the > handbook regarding NAT ( > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when > one places the NAT rules with the opposite order (i.e. outbound > rule first and then the inbound rule) the problem disappears. > > i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000 > nat 123 ip from any to any in recv em0 ... > > Why is this happening? Any objections to reversing the order of the > NAT rules? _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To > unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJVlDldXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkigQAMhJSo5UaDxrAz5RmMt1KjJX 5kXKXe35NLzI6J3bt/ZBBwmJSl1Z/17BEhTAMQmietAi5zVV8QD8DB+lq/jjvY3F TmADQ4O/b2Dml/Vgcg8fzv4Oai/fPENfNLZNItc/Hv9fxKtDUoxW3SehlTcti/DM 5VpIb0Td7o3WWEmtYMUHSvYIXpUQSr8IeE48Svd4dKJ7x7oJP11qpECa2vsDRJFc 8BM5jWWfJqfWcB//+G/9C9nT4DbTHhwrP4UkvZDwM2mc8xz5gzEtwXUDPle8Bgtb StHrMkrgZvGfGWd95dPVm3oTdhIVvv3KSNW47PCo/xRVz8ZQKog2N4QYrNIUzhbL Igmxus3VD4uwqr+3z+lB5lgUYMeB0pqnEihWGAQ15cwxNRlEEFOg/hGZTiNx9u88 2/UcK6up2jtxBTXy2Tf/CWL12PqnkDxsC2drZULDOR9P/XT3YcB++ie6Xz9iv7rt 3C8hOQ3B8LqAKfTP4LG2vh1uv4X6Vw7sfx3vpGXr3bQFaZt/odesI3/SiWaSmkNi bu6JKU2QnepLRrKObeggIap4SSRq7AKZiVa+O5R3HJFAhsFLutgHIYP1G7+BzHAX OCHRXgHiWDNNKa9tzUQgdS372kM+kP10vbY74TJ2dEL3Nwc9XehiasToEVfYhLin FG8VdsZZSi+wA8Pg3YbQ =kzTV -----END PGP SIGNATURE-----