From owner-freebsd-net@FreeBSD.ORG Fri Jan 30 00:37:46 2015 Return-Path: Delivered-To: freebsd-net@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 288CF1BA for ; Fri, 30 Jan 2015 00:37:46 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id DE2F6195 for ; Fri, 30 Jan 2015 00:37:45 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 897B15C002 for ; Fri, 30 Jan 2015 03:36:56 +0300 (MSK) Message-ID: <54CAD234.3020407@FreeBSD.org> Date: Fri, 30 Jan 2015 03:37:08 +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: freebsd-net@freebsd.org Subject: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 00:37:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have problems to understand how combination of nat and stateful ruleset for ipfw should work. There is no good guides, and most guides uses old "divert" which is different from in-kernel nat, as far as I understand. Problem is, if we want to allow only incoming packets which are belong to already established connections, we need to create state in "allow" out rule for outbound packet BEFORE nat rule and then pass it to nat, which looks impossible, as "allow" stop processing. Or we could pass it to nat and then "allow keep-state", but then there will be same problem for inbound packets: "check-state" should go before "nat" rule, but packet should be passed to nat after that! Now I have old ruleset which I don't quite understand. It works, but WHY? Now I have such rules for outbound packets: 12700 skipto 12900 ip from any to any keep-state 12800 deny ip from any to any 12900 nat 1 ip from any to any out 12999 allow ip from any to any And rules for inbound ones are: 11000 deny ip from any to not me 11500 nat 1 ip from any to any 11510 check-state 11600 allow tcp from any to me ssh,http setup keep-state 11999 deny ip from any to any It was migrated from old copy'n'pasted "divert" variant (created before "nat" action was created!). Looks like, it does not what I want at all! It works only by accident, as "check-state" becomes "skipto 12900" and it is works only because 12999 is "allow ip from any to any" and not some other filtration! Is here better way to have nat and stateful ruleset? BTW, if I add second outbound link and "nat global" + two "fwd" rules, thing become even worse, as rul 12700 doesn't see second outbound packet (because it is intercepted by "nat global") and TTL of dynamic rule becomes 10 seconds! I don't see any way to achieve my goal with "nat global", exactly because "skipto keep-state" should be placed almost before "allow" and "nat global" adds second way through ruleset. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUytIzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP5R4P/jiZlkbm5boUI5n6JOCuFK7F g2rkiRtJacS+r5D2AVka7v1MPpNh7EU1n+YWjFo+oFz1yZPuLVMPjm9na2Y2CkKE NwBjO4m4z5crjvFK8nP/p/KFjHujDGRsA+EMxUs0UjEIw5GtaGSURqozliKqQReb dSInAOFPXOElka7n1IGQaFh/C0JYU/V86pHYM0axRSJfVA5QNMNImCPjUF6ESO1/ Nn/TRbI5nu/F0MFp6+Wsq/44n59ehJDF/sRIAKXzvF0BMBC4W/i76RGdjDZEEPhn w1P5TvHiOimnBkgegtS5J1HZuF2a6JbNTnv9FrtE1wZqppWAUeCzrJKfV5NNlOWw kR2v1oEjP00Mrsst10jZOyWVrNduGQsBMb4JK1LB3S8+v9hCg0oYipXdWmOEq+V3 tShc714b1kcY5zciyKqA7b8DLIGmrIECKVgj4mwaNCT3Qrs23JE0/3SPVX4hUiJN z9DwLGEJxiQTguh0+1PbwAJXWsmkBRBdytjyiKbNZtjU97foDIutndugBE9INTpV qIFIVB8310y/GOikiSDbftK/Xvea1vwWvPV5VoH/DF3wkWb0Gs9t2fKAbsQ53Rvx ACINd5zCShCQpV6d9NzgtjSWOfN7au6mmU2o+1TuUbQzBMyhdpVX0XA2vxFBwCTk 9W6wHQC2NZLiSqFxq1Xd =Agj5 -----END PGP SIGNATURE-----