From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 15:20:01 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED8ACB4A; Wed, 4 Feb 2015 15:20:01 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id AA3D2638; Wed, 4 Feb 2015 15:20:01 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id ABD1C5C002; Wed, 4 Feb 2015 18:19:49 +0300 (MSK) Message-ID: <54D23895.5090701@FreeBSD.org> Date: Wed, 04 Feb 2015 18:19:49 +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.4.0 MIME-Version: 1.0 To: Jason Lewis Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> <20150204231922.X38620@sola.nimnet.asn.au> <54D2188D.5080800@FreeBSD.org> <54D21ADD.2090209@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Julian Elischer , Ian Smith X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:20:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04.02.2015 18:13, Jason Lewis wrote: > The possible issue is is that once NAT changes the IP address and > possibly the port number, state tracking can no longer be applied. > AKA, the packet headers before the NAT is different than the > packet headers after. This is why NAT needs to track the state > instead of ipfw. If you create state and check state on proper "ends" of NAT (for example, create state for connection BEFORE out-NAT, with internal addresses, and check it AFTER in-NAT, with internal addresses again), it will work. But now, when state creation is terminal action AND state checking in one box, it is hard to implement and leads to very non-intuitive rule sets. - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0jiVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTnQP/2kxqyTxUSa3RBLBsoq58iL4 IeGarQ7PrTVVaBTEVzhabU0yPuORpMqrwf47nImAZQWHcQP7UUjO+VjjqDthwwe8 S3CElbPFW86HmYLB7Nz1Lhg7n0eaKG6xxDO5um/b3cWuK7B3DiU+9oW7OHICF0Xa mk5Z9koVuAS3yuvT6PecSRgziV6HgxEKgYgNCgN+JmXWlL/H8kYUuYKBQTv1snkw hcRLKrRp31KavH8CRiTf6uBCozS4URvr6xRSfrkjcuU9LUlvHcI6jBCm7yOAEeDH HkcU5g5mNSK0vdJXZVmtveFADs8RrtAtovxt4FQZCjYPBhCDMRvM9IPQX8eK8tKX 8efJHb6DPIZQs+AeEhL1jeNJTu/UJRUag65Aua7TXq7jcopOMHM85aNMs6FzyqeG eT5Epc+oZ0Zbi0RAZzqvUeQSnARPE4tGddoOK5z5YMbF0jSiHM5ftfYncOp8YvDE uJMQAHOU4CHfuK/knzNkZ4VoD3+i+/fIiR4knNCLCe1wOvY9QmI+3iyk6JGZ4GJ9 vc7W+XCSnfuhFq5+o/8Lr+50z2qpmkJVaWoRW4DItWiHrWbx6dngL2aY8+e7TjEk 24rRQb16uYC6w3dUkNiKHMtUEaN+Zzju186jbQZpPjX6Rz4/9i2DJ6qYiZDWV28x e5TUOek2WeiROK+VvF/2 =XfPm -----END PGP SIGNATURE-----