From owner-freebsd-ipfw@freebsd.org Wed May 18 14:48:42 2016 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 C02D9B413B4 for ; Wed, 18 May 2016 14:48:42 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF7A11380; Wed, 18 May 2016 14:48:42 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 499E415AC; Wed, 18 May 2016 14:48:41 +0000 (UTC) (envelope-from ae@FreeBSD.org) To: freebsd-ipfw From: "Andrey V. Elsukov" Subject: [RFC] ipfw named states support Cc: lev@FreeBSD.org, luigi@FreeBSD.org, "Alexander V. Chernikov" Message-ID: <573C803E.5020600@FreeBSD.org> Date: Wed, 18 May 2016 17:46:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:48:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV Content-Type: multipart/mixed; boundary="UHeLs31xeiCGEXG7DTxf9593DlPdPh3k7" From: "Andrey V. Elsukov" To: freebsd-ipfw Cc: lev@FreeBSD.org, luigi@FreeBSD.org, "Alexander V. Chernikov" Message-ID: <573C803E.5020600@FreeBSD.org> Subject: [RFC] ipfw named states support --UHeLs31xeiCGEXG7DTxf9593DlPdPh3k7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, We have the patch that adds named states support to ipfw. The idea is that we add a symbolic name-label to each dynamic state in addition to IP addresses, protocol and ports. This introduces new syntax for check-state and keep-state rules: check-state { token | default | any } keep-state { token | default } The @token can contain symbols from the following mask: [a-zA-Z0-9\-_\.]{1,63} How it works ------------ "keep-state NAME" opcode creates state with assigned name NAME. This state can be matched only by 'keep-state NAME' or 'check-state NAME', or 'check-state any' opcodes. The "default" name used for compatibility with old rules. It is assigned to states when you omit the name on rule creating. So, # ipfw add check-state # ipfw add allow ip from any to any keep-state will produce: check-state default allow ip from any to any keep-state default But there is one problem, when your rule has some opcodes after 'keep-state' opcode (e.g. "keep-state in"). Such opcodes can be treated as state name. 'check-state any' matches states independently from the name. Why we need this ---------------- This expands flexibility and functionality. Imagine the situation: [ LAN1 ] <---> [ FW ] <---> [ LAN2 ] add skipto 10000 ip from any to any via lan1 add skipto 20000 ip from any to any via lan2 add deny ip from any to any add 10000 count ip from any to any ... add allow ip from to any keep-state in add deny ip from any to any add 20000 count ip from any to any ... add allow ip from to any keep-state in add deny ip from any to any The problem is that a state created by first keep-state rule will act on second keep-state rule and allow traffic to go into (out from router's point of view) lan2 without any rules actually allowing that. With named states we can create separate states for each interface and they will not match when we don't want this. What I want to discuss ---------------------- 1. Is this feature useful? 2. How to commit it? Due to changed syntax it can break existing rulesets. Probably, we can add some mandatory prefix to state name, e.g. ':'. --=20 WBR, Andrey V. Elsukov --UHeLs31xeiCGEXG7DTxf9593DlPdPh3k7-- --Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBCAAGBQJXPIA+AAoJEAHF6gQQyKF6T/EH9Rnk0GO69LyOMQnyPTGsHGNp VYK4elU8XDsuOLzfLKs+VO97upYHI+BmUvmzgFifpW7zWphSee2WR0PUUsM32gdy hexIIbnpWS7mW4VeIfnUrOP2Un+j41i3cUGKDqNWThrebqeA9ERS+knNhbkeisiM S5qM4UinEGMxbuGNwEYEZhbfkucj1+heNN6DkndnC/acMAL1fAyOqR8qsn8DMWW5 QH4UlduuxNTu4k4ezzYBmZcRI4RVCbPgJWVOemKVH0fxKkbK1368fpbMSlCgOARd Zv32BcuzobuMMpSHYQ9vAhddjj5KNnrIFAK2mJRTaNmhJ4CjSZLE0Ae8DTEcTw== =qS7k -----END PGP SIGNATURE----- --Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV--