From owner-freebsd-ipfw@FreeBSD.ORG Mon Dec 14 11:06:58 2009 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 3384F1065679 for ; Mon, 14 Dec 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1879D8FC0C for ; Mon, 14 Dec 2009 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEB6vTo075981 for ; Mon, 14 Dec 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEB6vvH075979 for freebsd-ipfw@FreeBSD.org; Mon, 14 Dec 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Dec 2009 11:06:57 GMT Message-Id: <200912141106.nBEB6vvH075979@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org 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, 14 Dec 2009 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem p kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 63 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 17 07:49:18 2009 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 D19181065672; Thu, 17 Dec 2009 07:49:18 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 35B1F8FC14; Thu, 17 Dec 2009 07:49:17 +0000 (UTC) Received: by fxm27 with SMTP id 27so1671420fxm.3 for ; Wed, 16 Dec 2009 23:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=uNQQy5JqI86IK7raVSQOhvqyPLJStrhAMrAEyg8JWzo=; b=TAwyecXX1QFUP7l74HqppAj59qyKU7YECUNrMqOFEPK5YcpbKguH625i7ZOJtdn7o1 IhiUF5MWwULm7fhNt0qiUZ9Ol0CWp7bi9aLaeMZx+5EsF/eqcumDZD/6xLAR2L/ejyeM ycwU3QpzvT9vlnJcjwO8Puwo6BEAaiSYwEdKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ai5dJhX+Qtq/yVb0KaQnx4WZnO1+b0cb2H7SRR9ccztpXamD1FvbvOlomP46Uwq9CN rNwNjPvKZ1g7Ije7NkmA6oIpCU1k+eNMIN1HZ8zy6Emc6KlEFFKIdsi3ZN6aDCVrzL/y jRn/zIH9IE2aib1OOXz90S+0EjN5j1jVhsXH8= MIME-Version: 1.0 Received: by 10.239.138.13 with SMTP id n13mr214225hbn.9.1261034447934; Wed, 16 Dec 2009 23:20:47 -0800 (PST) Date: Thu, 17 Dec 2009 02:20:47 -0500 Message-ID: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> From: David Horn To: Hajimu UMEMOTO , freebsd-ipfw@freebsd.org Content-Type: multipart/mixed; boundary=001485f78b4851964f047ae7768a X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Unified rc.firewall ipfw me/me6 issue 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: Thu, 17 Dec 2009 07:49:18 -0000 --001485f78b4851964f047ae7768a Content-Type: text/plain; charset=ISO-8859-1 Hajimu -- Thanks for working on rc.firewall, as the old scenario of dualing rc.firewall/rc.firewall6 was not easily used in the default configurations when running dual stack. The new rc.firewall has some very decent sane defaults. My testing so far as been concentrated on firewall_type="client", dual stack v4/v6 with SLAAC for IPv6, and DHCP for IPv4. I will try some of the IPv6 tunnel scenarios later. I ran some tests against the now committed to -current /etc/rc.firewall, and think have found an issue. In every line that has the "me" token without the equivalent "me6" token, the command is only taking affect for ipv4. For example: ${fwcmd} add pass udp from me to any 53 keep-state will allow dns requests from the client to pass, but if the destination host is ipv6, this rule does not work. Instead you need: ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state The same issue exists for several other entries as well. (possible diff attached) The other option is to modify ipfw to actually have three different "me" tokens (me/me4/me6) where the new "me" token would match both ipv4 and ipv6 local interface addresses. Currently "me" matches only ipv4 addresses on my amd64 -current box. Thoughts anyone? --Thanks! -_Dave Horn P.S., might also be nice to have an UPDATING entry for unified rc.firewall --001485f78b4851964f047ae7768a Content-Type: text/plain; charset=US-ASCII; name="rc.firewall.diff.txt" Content-Disposition: attachment; filename="rc.firewall.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g3b693g00 SW5kZXg6IGV0Yy9yYy5maXJld2FsbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBldGMvcmMuZmlyZXdhbGwJKHJl dmlzaW9uIDIwMDYyMykKKysrIGV0Yy9yYy5maXJld2FsbAkod29ya2luZyBjb3B5KQpAQCAtMjI5 LDE5ICsyMjksMTkgQEAKIAkke2Z3Y21kfSBhZGQgcGFzcyBhbGwgZnJvbSBhbnkgdG8gYW55IGZy YWcKIAogCSMgQWxsb3cgc2V0dXAgb2YgaW5jb21pbmcgZW1haWwKLQkke2Z3Y21kfSBhZGQgcGFz cyB0Y3AgZnJvbSBhbnkgdG8gbWUgMjUgc2V0dXAKKwkke2Z3Y21kfSBhZGQgcGFzcyB0Y3AgZnJv bSBhbnkgdG8geyBtZSBvciBtZTYgfSAyNSBzZXR1cAogCiAJIyBBbGxvdyBzZXR1cCBvZiBvdXRn b2luZyBUQ1AgY29ubmVjdGlvbnMgb25seQotCSR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIG1l IHRvIGFueSBzZXR1cAorCSR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIHsgbWUgb3IgbWU2IH0g dG8gYW55IHNldHVwCiAKIAkjIERpc2FsbG93IHNldHVwIG9mIGFsbCBvdGhlciBUQ1AgY29ubmVj dGlvbnMKIAkke2Z3Y21kfSBhZGQgZGVueSB0Y3AgZnJvbSBhbnkgdG8gYW55IHNldHVwCiAKIAkj IEFsbG93IEROUyBxdWVyaWVzIG91dCBpbiB0aGUgd29ybGQKLQkke2Z3Y21kfSBhZGQgcGFzcyB1 ZHAgZnJvbSBtZSB0byBhbnkgNTMga2VlcC1zdGF0ZQorCSR7ZndjbWR9IGFkZCBwYXNzIHVkcCBm cm9tIHsgbWUgb3IgbWU2IH0gdG8gYW55IDUzIGtlZXAtc3RhdGUKIAogCSMgQWxsb3cgTlRQIHF1 ZXJpZXMgb3V0IGluIHRoZSB3b3JsZAotCSR7ZndjbWR9IGFkZCBwYXNzIHVkcCBmcm9tIG1lIHRv IGFueSAxMjMga2VlcC1zdGF0ZQorCSR7ZndjbWR9IGFkZCBwYXNzIHVkcCBmcm9tIHsgbWUgb3Ig bWU2IH0gdG8gYW55IDEyMyBrZWVwLXN0YXRlCiAKIAkjIEV2ZXJ5dGhpbmcgZWxzZSBpcyBkZW5p ZWQgYnkgZGVmYXVsdCwgdW5sZXNzIHRoZQogCSMgSVBGSVJFV0FMTF9ERUZBVUxUX1RPX0FDQ0VQ VCBvcHRpb24gaXMgc2V0IGluIHlvdXIga2VybmVsCkBAIC0zODcsMTUgKzM4NywxNSBAQAogCSR7 ZndjbWR9IGFkZCBwYXNzIGFsbCBmcm9tIGFueSB0byBhbnkgZnJhZwogCiAJIyBBbGxvdyBzZXR1 cCBvZiBpbmNvbWluZyBlbWFpbAotCSR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIGFueSB0byBt ZSAyNSBzZXR1cAorCSR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIGFueSB0byB7IG1lIG9yIG1l NiB9IDI1IHNldHVwCiAKIAkjIEFsbG93IGFjY2VzcyB0byBvdXIgRE5TCi0JJHtmd2NtZH0gYWRk IHBhc3MgdGNwIGZyb20gYW55IHRvIG1lIDUzIHNldHVwCi0JJHtmd2NtZH0gYWRkIHBhc3MgdWRw IGZyb20gYW55IHRvIG1lIDUzCi0JJHtmd2NtZH0gYWRkIHBhc3MgdWRwIGZyb20gbWUgNTMgdG8g YW55CisJJHtmd2NtZH0gYWRkIHBhc3MgdGNwIGZyb20gYW55IHRvIHsgbWUgb3IgbWU2IH0gNTMg c2V0dXAKKwkke2Z3Y21kfSBhZGQgcGFzcyB1ZHAgZnJvbSBhbnkgdG8geyBtZSBvciBtZTYgfSA1 MworCSR7ZndjbWR9IGFkZCBwYXNzIHVkcCBmcm9tIHsgbWUgb3IgbWU2IH0gNTMgdG8gYW55CiAK IAkjIEFsbG93IGFjY2VzcyB0byBvdXIgV1dXCi0JJHtmd2NtZH0gYWRkIHBhc3MgdGNwIGZyb20g YW55IHRvIG1lIDgwIHNldHVwCisJJHtmd2NtZH0gYWRkIHBhc3MgdGNwIGZyb20gYW55IHRvIHsg bWUgb3IgbWU2IH0gODAgc2V0dXAKIAogCSMgUmVqZWN0JkxvZyBhbGwgc2V0dXAgb2YgaW5jb21p bmcgY29ubmVjdGlvbnMgZnJvbSB0aGUgb3V0c2lkZQogCSR7ZndjbWR9IGFkZCBkZW55IGxvZyBp cDQgZnJvbSBhbnkgdG8gYW55IGluIHZpYSAke29pZn0gc2V0dXAgcHJvdG8gdGNwCkBAIC00MDgs MTAgKzQwOCwxMCBAQAogCSR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIGFueSB0byBhbnkgc2V0 dXAKIAogCSMgQWxsb3cgRE5TIHF1ZXJpZXMgb3V0IGluIHRoZSB3b3JsZAotCSR7ZndjbWR9IGFk ZCBwYXNzIHVkcCBmcm9tIG1lIHRvIGFueSA1MyBrZWVwLXN0YXRlCisJJHtmd2NtZH0gYWRkIHBh c3MgdWRwIGZyb20geyBtZSBvciBtZTYgfSB0byBhbnkgNTMga2VlcC1zdGF0ZQogCiAJIyBBbGxv dyBOVFAgcXVlcmllcyBvdXQgaW4gdGhlIHdvcmxkCi0JJHtmd2NtZH0gYWRkIHBhc3MgdWRwIGZy b20gbWUgdG8gYW55IDEyMyBrZWVwLXN0YXRlCisJJHtmd2NtZH0gYWRkIHBhc3MgdWRwIGZyb20g eyBtZSBvciBtZTYgfSB0byBhbnkgMTIzIGtlZXAtc3RhdGUKIAogCSMgRXZlcnl0aGluZyBlbHNl IGlzIGRlbmllZCBieSBkZWZhdWx0LCB1bmxlc3MgdGhlCiAJIyBJUEZJUkVXQUxMX0RFRkFVTFRf VE9fQUNDRVBUIG9wdGlvbiBpcyBzZXQgaW4geW91ciBrZXJuZWwK --001485f78b4851964f047ae7768a-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 17 08:36:14 2009 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 EAAF11065679 for ; Thu, 17 Dec 2009 08:36:14 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 509958FC15 for ; Thu, 17 Dec 2009 08:36:14 +0000 (UTC) Received: from ameno.mahoroba.org (IDENT:wliZOpZvyzj8CT7jmKi4DT+lOsbEGpAhgYfQzri1fRyds+LBarzrS6lpyROrxm9I@ameno.mahoroba.org [IPv6:2001:2f0:104:8010:20a:79ff:fe69:ee6b]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nBH8a0n7046123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 17:36:08 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 17 Dec 2009 17:36:00 +0900 Message-ID: From: Hajimu UMEMOTO To: David Horn In-Reply-To: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> User-Agent: xcite1.58> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE-p1 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Thu_Dec_17_17:36:00_2009-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 17 Dec 2009 17:36:08 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue 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: Thu, 17 Dec 2009 08:36:15 -0000 --Multipart_Thu_Dec_17_17:36:00_2009-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Thu, 17 Dec 2009 02:20:47 -0500 >>>>> David Horn said: dhorn2000> Thanks for working on rc.firewall, as the old scenario of dualing dhorn2000> rc.firewall/rc.firewall6 was not easily used in the default configurations dhorn2000> when running dual stack. The new rc.firewall has some very decent sane dhorn2000> defaults. My testing so far as been concentrated on firewall_type="client", dhorn2000> dual stack v4/v6 with SLAAC for IPv6, and DHCP for IPv4. I will try some of dhorn2000> the IPv6 tunnel scenarios later. There is no rule to pass the IPv6 over IPv4 tunnel. You need to add it by yourself for now. I thought it may better having it for our default rule. However, I didn't come up with suitable default. So, I didn't add it. dhorn2000> I ran some tests against the now committed to -current /etc/rc.firewall, and dhorn2000> think have found an issue. In every line that has the "me" token without dhorn2000> the equivalent "me6" token, the command is only taking affect for ipv4. Yes, thank you for the report. It's my mistake. The default rule should have same behavior as possible between an IPv4 and an IPv6. dhorn2000> ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state Your proposed patch is simple enough, thus I like it. However, we need to consider the environment where the kernel doesn't have an IPv6 support. So, we cannot just use '{ me or me6 }', here. How about the attached patch, instead? Sorry, but I have no test environment for now. So, I don't test it by my self, yet. I'll test it later. dhorn2000> The same issue exists for several other entries as well. (possible diff dhorn2000> attached) The other option is to modify ipfw to actually have three dhorn2000> different "me" tokens (me/me4/me6) where the new "me" token would match both dhorn2000> ipv4 and ipv6 local interface addresses. Currently "me" matches only ipv4 dhorn2000> addresses on my amd64 -current box. I think 'me' matches both an IPv4 and an IPv6 is better. dhorn2000> P.S., might also be nice to have an UPDATING entry for unified rc.firewall Yes, it should be. I'll add an UPDATING entry later. Sincerely, --Multipart_Thu_Dec_17_17:36:00_2009-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="rc.firewall-me6.diff" Content-Transfer-Encoding: 7bit Index: etc/rc.firewall diff -u etc/rc.firewall.orig etc/rc.firewall --- etc/rc.firewall.orig 2009-12-03 00:05:26.000000000 +0900 +++ etc/rc.firewall 2009-12-17 17:04:40.000000000 +0900 @@ -230,18 +230,30 @@ # Allow setup of incoming email ${fwcmd} add pass tcp from any to me 25 setup + if [ -n "$net6" ]; then + ${fwcmd} add pass tcp from any to me6 25 setup + fi # Allow setup of outgoing TCP connections only ${fwcmd} add pass tcp from me to any setup + if [ -n "$net6" ]; then + ${fwcmd} add pass tcp from me6 to any setup + fi # Disallow setup of all other TCP connections ${fwcmd} add deny tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from me to any 53 keep-state + if [ -n "$net6" ]; then + ${fwcmd} add pass udp from me6 to any 53 keep-state + fi # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + if [ -n "$net6" ]; then + ${fwcmd} add pass udp from me6 to any 123 keep-state + fi # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel @@ -388,14 +400,25 @@ # Allow setup of incoming email ${fwcmd} add pass tcp from any to me 25 setup + if [ -n "$inet6" ]; then + ${fwcmd} add pass tcp from any to me6 25 setup + fi # Allow access to our DNS ${fwcmd} add pass tcp from any to me 53 setup ${fwcmd} add pass udp from any to me 53 ${fwcmd} add pass udp from me 53 to any + if [ -n "$inet6" ]; then + ${fwcmd} add pass tcp from any to me6 53 setup + ${fwcmd} add pass udp from any to me6 53 + ${fwcmd} add pass udp from me6 53 to any + fi # Allow access to our WWW ${fwcmd} add pass tcp from any to me 80 setup + if [ -n "$inet6" ]; then + ${fwcmd} add pass tcp from any to me6 80 setup + fi # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp @@ -409,9 +432,15 @@ # Allow DNS queries out in the world ${fwcmd} add pass udp from me to any 53 keep-state + if [ -n "$inet6" ]; then + ${fwcmd} add pass udp from me6 to any 53 keep-state + fi # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + if [ -n "$inet6" ]; then + ${fwcmd} add pass udp from me6 to any 123 keep-state + fi # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel --Multipart_Thu_Dec_17_17:36:00_2009-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Thu_Dec_17_17:36:00_2009-1-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 17 17:31:34 2009 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 0B5B81065693 for ; Thu, 17 Dec 2009 17:31:34 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 987A88FC0A for ; Thu, 17 Dec 2009 17:31:33 +0000 (UTC) Received: by fxm27 with SMTP id 27so2138421fxm.3 for ; Thu, 17 Dec 2009 09:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=kYrEfFYKFLcfcAoE0+utHDZWR6qfhT7enDJeHB8sDZM=; b=EPce7JQ+yXrZyYOb1t032SvUi+hejsDakpIjC8WhNN6TOujtev17PpZ2e90X++dQb1 Yz19T/yoWRSFKkQpQJJze3KY4pCsMnr0ZVm8siVwvLAfYAmbE+bQj+2FYKvnE8lNRPbF fk7vqyZHzNIQv1zVoIQ/ZEgx81CVqyZr5164I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=moGZoDZbyvcZjKpantvk+l7gzOTVPCSdsySLGvBQLBNfzAvaO+i6WGKm7QIM51oH9l Im61j7n8cNXflR1Oy6AzuwfXZoxl6sC2TrL1qk/k949qEs+cfW4xSOlsV/dO7kGrxolJ ZXOJ2U9LpyQaUJfjfF52Jihz3i7EeZbOORtBs= MIME-Version: 1.0 Received: by 10.239.136.133 with SMTP id h5mr265911hbh.126.1261071092518; Thu, 17 Dec 2009 09:31:32 -0800 (PST) Date: Thu, 17 Dec 2009 12:31:32 -0500 Message-ID: <25ff90d60912170931qd6109w91409ebb225791dc@mail.gmail.com> From: David Horn To: Luigi Rizzo , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: r200580 ipfw.ko kldload failure 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: Thu, 17 Dec 2009 17:31:34 -0000 Luigi -- I am seeing a kldload failure for ipfw.ko after the latest -current commits (fails for r200580 - r200633 inclusive) for ipfw: link_elf_obj: symbol ipfw_dyn_attach undefined linker_load_file: Unsupported file type dhorn-1520# uname -a FreeBSD dhorn-1520 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r200623M: Thu Dec 17 01:42:13 EST 2009 root@dhorn-1520:/usr/obj/usr/src/sys/DHORN amd64 The latest svn revision that kldload ipfw.ko works properly for me is r200567. (amd64 GENERIC + ahci + ATA_CAM in kernel config) As well, in an attempt to test a separate fix for /etc/rc.firewall, I was attempting to do this without INET6 in my kernel config, and ipfw failed to load on r200567 with a different error: link_elf_obj: symbol in6_cksum undefined linker_load_file: Unsupported file type I have not attempted to go back to revisions prior to r200567 yet. Let me know if you need me to narrow the no INET6 case down to a specific commit. --Thanks! ---Dave Horn From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 17 17:46:25 2009 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 812BB1065743 for ; Thu, 17 Dec 2009 17:46:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 472A98FC08 for ; Thu, 17 Dec 2009 17:46:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2E876730A1; Thu, 17 Dec 2009 18:53:52 +0100 (CET) Date: Thu, 17 Dec 2009 18:53:52 +0100 From: Luigi Rizzo To: David Horn Message-ID: <20091217175352.GA69780@onelab2.iet.unipi.it> References: <25ff90d60912170931qd6109w91409ebb225791dc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25ff90d60912170931qd6109w91409ebb225791dc@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: r200580 ipfw.ko kldload failure 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: Thu, 17 Dec 2009 17:46:25 -0000 On Thu, Dec 17, 2009 at 12:31:32PM -0500, David Horn wrote: > Luigi -- > > I am seeing a kldload failure for ipfw.ko after the latest -current commits > (fails for r200580 - r200633 inclusive) for ipfw: > > link_elf_obj: symbol ipfw_dyn_attach undefined not surprising, as i forgot to put the new filenames in the Makefile for the module, and buildworld does not (and cannot) complain about unresolved symbols. Just committed a fix in r200636 thanks luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 17 23:58:32 2009 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 12395106566B for ; Thu, 17 Dec 2009 23:58:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9B48C8FC17 for ; Thu, 17 Dec 2009 23:58:31 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-067-230-017.pools.arcor-ip.net [88.67.230.17]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LdIgf-1NlzPu14hl-00i0Fg; Fri, 18 Dec 2009 00:45:55 +0100 Received: (qmail 40999 invoked from network); 17 Dec 2009 23:45:54 -0000 Received: from f8x64.laiers.local (192.168.4.188) by ns1.laiers.local with SMTP; 17 Dec 2009 23:45:54 -0000 From: Max Laier Organization: FreeBSD To: freebsd-ipfw@freebsd.org Date: Fri, 18 Dec 2009 00:45:53 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE; KDE/4.3.4; amd64; ; ) References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> In-Reply-To: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912180045.53942.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+zHpCsw0bPpVAslA3Dig4/WjOQy4+HvUpZo+4 Rsg/yvG4kYYI1Rdv41si3sjmVP6mtM6Yb36diwHqOpfZmBZfIL SDdP3M23sK4lfmb6TsVTw== Cc: David Horn , Hajimu UMEMOTO Subject: Re: Unified rc.firewall ipfw me/me6 issue 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: Thu, 17 Dec 2009 23:58:32 -0000 On Thursday 17 December 2009 08:20:47 David Horn wrote: > Hajimu -- > > Thanks for working on rc.firewall, as the old scenario of dualing > rc.firewall/rc.firewall6 was not easily used in the default configurations > when running dual stack. The new rc.firewall has some very decent sane > defaults. My testing so far as been concentrated on > firewall_type="client", dual stack v4/v6 with SLAAC for IPv6, and DHCP for > IPv4. I will try some of the IPv6 tunnel scenarios later. > > I ran some tests against the now committed to -current /etc/rc.firewall, > and think have found an issue. In every line that has the "me" token > without the equivalent "me6" token, the command is only taking affect for > ipv4. > > For example: > > ${fwcmd} add pass udp from me to any 53 keep-state > > will allow dns requests from the client to pass, but if the destination > host is ipv6, this rule does not work. Instead you need: > > ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state > > The same issue exists for several other entries as well. (possible diff > attached) The other option is to modify ipfw to actually have three > different "me" tokens (me/me4/me6) where the new "me" token would match > both ipv4 and ipv6 local interface addresses. Currently "me" matches only > ipv4 addresses on my amd64 -current box. The problem with this approach is and has been that it would change the meaning of "me". IIRC, it was considered a POLA violation to do that back when the IPv6 functionality was merged. An alternative would be to introduce a new name for me when we don't care which address family - e.g. me_any, mine, me64, me12, ... pick your color. > Thoughts anyone? > > --Thanks! > > -_Dave Horn > > P.S., might also be nice to have an UPDATING entry for unified rc.firewall > > > !DSPAM:4b29e29a301561928620662! > From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 18 00:22:33 2009 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 34D1910656AE for ; Fri, 18 Dec 2009 00:22:33 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5058FC22 for ; Fri, 18 Dec 2009 00:22:32 +0000 (UTC) Received: by pzk15 with SMTP id 15so1770339pzk.3 for ; Thu, 17 Dec 2009 16:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Whg3g0s1LJwZrgRDHjlhOQWPx8lP79zVt8HZJ4L7pn8=; b=LXpBXcyBghNi7OusaJesI0MEsf0D0bwaiXflNqCyuNpXQAsD3LbbW6fj7EUnqtTmYi S17l3w4kstaC9EBvvEpFuOsQZl1/l4bAhjg+Hp9KsPu8MhNJXQMirpvFVuLA8T+UaXA6 4lSGDJBQGz721UlRqexA98ODY4OfQVFJrRVGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mnn7VywBhFUy5oSI0Y+8piJFcsuN48lqlozQKCe8jz6H0EjR2tDpxF6ZVFo3I9ieD+ 0w1JTwslkpWxTxowgxWkq01O/Qr7sL5E2Ngb9vLVVBszwUW2McXL5mMMV/qciIjrPMWE eKBvGKdzSaHAs/tKuL1Nji8rsPwcfggv8bng8= MIME-Version: 1.0 Received: by 10.143.154.33 with SMTP id g33mr2081110wfo.300.1261095752262; Thu, 17 Dec 2009 16:22:32 -0800 (PST) In-Reply-To: <200912180045.53942.max@love2party.net> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <200912180045.53942.max@love2party.net> Date: Thu, 17 Dec 2009 16:22:32 -0800 Message-ID: From: Freddie Cash To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Unified rc.firewall ipfw me/me6 issue 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: Fri, 18 Dec 2009 00:22:33 -0000 On Thu, Dec 17, 2009 at 3:45 PM, Max Laier wrote: > On Thursday 17 December 2009 08:20:47 David Horn wrote: > > Thanks for working on rc.firewall, as the old scenario of dualing > > rc.firewall/rc.firewall6 was not easily used in the default > configurations > > when running dual stack. The new rc.firewall has some very decent sane > > defaults. My testing so far as been concentrated on > > firewall_type="client", dual stack v4/v6 with SLAAC for IPv6, and DHCP > for > > IPv4. I will try some of the IPv6 tunnel scenarios later. > > > > I ran some tests against the now committed to -current /etc/rc.firewall, > > and think have found an issue. In every line that has the "me" token > > without the equivalent "me6" token, the command is only taking affect > for > > ipv4. > > > > For example: > > > > ${fwcmd} add pass udp from me to any 53 keep-state > > > > will allow dns requests from the client to pass, but if the destination > > host is ipv6, this rule does not work. Instead you need: > > > > ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state > > > > The same issue exists for several other entries as well. (possible diff > > attached) The other option is to modify ipfw to actually have three > > different "me" tokens (me/me4/me6) where the new "me" token would match > > both ipv4 and ipv6 local interface addresses. Currently "me" matches > only > > ipv4 addresses on my amd64 -current box. > > The problem with this approach is and has been that it would change the > meaning of "me". IIRC, it was considered a POLA violation to do that back > when the IPv6 functionality was merged. An alternative would be to > introduce a > new name for me when we don't care which address family - e.g. me_any, > mine, > me64, me12, ... pick your color. > > But it doesn't change the meaning of "me". "me" is any IP address configured on any interface. In that sense, there shouldn't be any differentiation between IPv4 and IPv6, since both are IP. If we wanted to be pedantic and keep things consistent, then why isn't there an "any6" keyword? ;) "me" should be any IP address configured on any interface, regardless of IP version. "me4" should be any IPv4 address configured on any interface. "me6" should be any IPv6 address configured on any interface. Having just "me" and "me6" is inconsistent and illogical, Jim. ;) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 18 05:42:50 2009 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 6168A106566B for ; Fri, 18 Dec 2009 05:42:50 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 0512F8FC0C for ; Fri, 18 Dec 2009 05:42:48 +0000 (UTC) Received: (qmail 1919 invoked from network); 18 Dec 2009 03:12:08 -0200 Received: by simscan 1.4.0 ppid: 1914, pid: 1917, t: 0.1030s scanners:none Received: from unknown (HELO webmail.freebsdbrasil.com.br) (127.0.0.1) by capeta.freebsdbrasil.com.br with ESMTP; 18 Dec 2009 03:12:08 -0200 X-Squirrel-UserHash: AxkWAwQSJAQABBYLHxAOFgAYDBVIEQoITBEW X-Squirrel-FromHash: BBZUBAFBXFQ= Message-ID: <53592.BBZUBAFBXFQ=.1261113128.squirrel@webmail.freebsdbrasil.com.br> Date: Fri, 18 Dec 2009 03:12:08 -0200 (BRST) From: eksffa@freebsdbrasil.com.br To: freebsd-ipfw@freebsd.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: ipfw modip - PR121122 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: Fri, 18 Dec 2009 05:42:50 -0000 Context: http://www.freebsd.org/cgi/query-pr.cgi?pr=121122 http://code.google.com/p/exports/wiki/ToSWorkAround http://forums.freebsd.org/showthread.php?t=7306 Any chance we will see Marcelo's work (or a derivative) commited to base? Are there serious implications or potential side effects on adding it? Its useful in proxy and voip environments and is also good for input normalization when you need to set some ToS bit to normal when its coming modified from Internet into your network. Thank you. From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 18 05:51:21 2009 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 9C52A106566B for ; Fri, 18 Dec 2009 05:51:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outb.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 84E7F8FC08 for ; Fri, 18 Dec 2009 05:51:21 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 231F596EF5; Thu, 17 Dec 2009 21:51:21 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C78922D6010; Thu, 17 Dec 2009 21:51:20 -0800 (PST) Message-ID: <4B2B1865.8060308@elischer.org> Date: Thu, 17 Dec 2009 21:51:33 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: eksffa@freebsdbrasil.com.br References: <53592.BBZUBAFBXFQ=.1261113128.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <53592.BBZUBAFBXFQ=.1261113128.squirrel@webmail.freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw modip - PR121122 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: Fri, 18 Dec 2009 05:51:21 -0000 eksffa@freebsdbrasil.com.br wrote: > Context: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121122 > http://code.google.com/p/exports/wiki/ToSWorkAround > http://forums.freebsd.org/showthread.php?t=7306 > > Any chance we will see Marcelo's work (or a derivative) commited to base? > Are there serious implications or potential side effects on adding it? > > Its useful in proxy and voip environments and is also good for input > normalization when you need to set some ToS bit to normal when its coming > modified from Internet into your network. > > Thank you. there are actually a lot of ipfw bug reorts with patches like this and I'm hoping that luigi, since he's actually elbow deep in it at teh moment might be able to take some of them in while he's in there. This one included... > > _______________________________________________ > 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" From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 18 14:12:51 2009 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 1F991106566B; Fri, 18 Dec 2009 14:12:51 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 63D7C8FC14; Fri, 18 Dec 2009 14:12:49 +0000 (UTC) Received: by fxm27 with SMTP id 27so2865903fxm.3 for ; Fri, 18 Dec 2009 06:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yRyuYMp/gUoq2vBe6DUWRZYZjzaLPHzoC8EQrZqMZ+o=; b=KSAQPrkqgiODffmsMnzaPmzHAZinE9M3Iz+k6hZqbpP/vxsYof0eHC7uMsABibrfb6 FD7wdiJP2XfujjBhA64JpapHhpQoYP4c6aO2AtZVWZAR1YfwEuKStDV2ncqlGuXYNkbV 8su7r81EWe8Pp2ZY6hfbi5PmE8j0oHg43VW5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E156O+ZO4JxjcpXLO61yw5FUu3dUadS9C2XScvj7Pm1HcFNZ5FwVp1pzJ0i9hD0y0W OEIFmIX4fVdZ+nK3yiIHyfcsXYC993ZQWZyUwha15tRSt6FE4bcg4u6gDpMW9FsBHYvZ 5dYn86OMPYg5JPcr2uccUOpi6hjLAWI+Ru2UQ= MIME-Version: 1.0 Received: by 10.239.179.101 with SMTP id c37mr394264hbg.4.1261145568943; Fri, 18 Dec 2009 06:12:48 -0800 (PST) In-Reply-To: References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> Date: Fri, 18 Dec 2009 09:12:48 -0500 Message-ID: <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> From: David Horn To: Hajimu UMEMOTO Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue 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: Fri, 18 Dec 2009 14:12:51 -0000 On Thu, Dec 17, 2009 at 3:36 AM, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Thu, 17 Dec 2009 02:20:47 -0500 > >>>>> David Horn said: > > dhorn2000> Thanks for working on rc.firewall, as the old scenario of > dualing > dhorn2000> rc.firewall/rc.firewall6 was not easily used in the default > configurations > dhorn2000> when running dual stack. The new rc.firewall has some very > decent sane > dhorn2000> defaults. My testing so far as been concentrated on > firewall_type="client", > dhorn2000> dual stack v4/v6 with SLAAC for IPv6, and DHCP for IPv4. I will > try some of > dhorn2000> the IPv6 tunnel scenarios later. > > There is no rule to pass the IPv6 over IPv4 tunnel. You need to add > it by yourself for now. I thought it may better having it for our > default rule. However, I didn't come up with suitable default. So, I > didn't add it. > > dhorn2000> I ran some tests against the now committed to -current > /etc/rc.firewall, and > dhorn2000> think have found an issue. In every line that has the "me" > token without > dhorn2000> the equivalent "me6" token, the command is only taking affect > for ipv4. > > Yes, thank you for the report. It's my mistake. The default rule > should have same behavior as possible between an IPv4 and an IPv6. > > dhorn2000> ${fwcmd} add pass udp from { me or me6 } to any 53 keep-state > > Your proposed patch is simple enough, thus I like it. However, we need > to consider the environment where the kernel doesn't have an IPv6 > support. So, we cannot just use '{ me or me6 }', here. > How about the attached patch, instead? Sorry, but I have no test > environment for now. So, I don't test it by my self, yet. I'll test > it later. > The updated patch works, but doing a check for [ $ipv6_available -eq 0 ] might be more appropriate than checking "net6" or "inet6" variables in these no INET6 cases since neither net6 or inet6 variables are involved in these statements. > > dhorn2000> The same issue exists for several other entries as well. > (possible diff > dhorn2000> attached) The other option is to modify ipfw to actually have > three > dhorn2000> different "me" tokens (me/me4/me6) where the new "me" token > would match both > dhorn2000> ipv4 and ipv6 local interface addresses. Currently "me" matches > only ipv4 > dhorn2000> addresses on my amd64 -current box. > > I think 'me' matches both an IPv4 and an IPv6 is better. > Yes, "me" matching either ipv4/ipv6 would certainly simplify the default rc.firewall flow. > > dhorn2000> P.S., might also be nice to have an UPDATING entry for unified > rc.firewall > > Yes, it should be. I'll add an UPDATING entry later. > > Sincerely, > > > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ > > I am continuing to evaluate and may have some additional tweaks to other areas in a few days. --Thanks! --Dave Horn From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 18 15:45:51 2009 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 EB9EC106566B for ; Fri, 18 Dec 2009 15:45:50 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6104B8FC14 for ; Fri, 18 Dec 2009 15:45:50 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nBIFjOV8014003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Dec 2009 00:45:29 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 19 Dec 2009 00:45:23 +0900 Message-ID: From: Hajimu UMEMOTO To: David Horn In-Reply-To: <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sat_Dec_19_00:45:23_2009-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 19 Dec 2009 00:45:29 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 issue 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: Fri, 18 Dec 2009 15:45:51 -0000 --Multipart_Sat_Dec_19_00:45:23_2009-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Fri, 18 Dec 2009 09:12:48 -0500 >>>>> David Horn said: dhorn2000> The updated patch works, but doing a check for [ $ipv6_available -eq 0 ] dhorn2000> might be more appropriate than checking "net6" or "inet6" variables in these dhorn2000> no INET6 cases since neither net6 or inet6 variables are involved in these dhorn2000> statements. Thank you for testing. It is intentional. If firewall_client_net_ipv6 is not set, the IPv6 rules are not meaningful for the client type, and if firewall_simple_inet_ipv6 is not set, the IPv6 rules are not meaningful for the simple type. dhorn2000> Yes, "me" matching either ipv4/ipv6 would certainly simplify the default dhorn2000> rc.firewall flow. Here is my proposed patch. With this patch, 'me' matches to both IPv4 and IPv6, and 'me4' is added for matching to only IPv4. Sincerely, --Multipart_Sat_Dec_19_00:45:23_2009-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-me-unify.diff" Content-Transfer-Encoding: 7bit Index: sbin/ipfw/ipfw2.c =================================================================== --- sbin/ipfw/ipfw2.c (revision 200668) +++ sbin/ipfw/ipfw2.c (working copy) @@ -768,6 +768,10 @@ printf("me"); return; } + if (cmd->o.opcode == O_IP4_SRC_ME || cmd->o.opcode == O_IP4_DST_ME) { + printf("me4"); + return; + } if (cmd->o.opcode == O_IP_SRC_LOOKUP || cmd->o.opcode == O_IP_DST_LOOKUP) { printf("table(%u", ((ipfw_insn *)cmd)->arg1); @@ -1187,6 +1191,7 @@ case O_IP_SRC_LOOKUP: case O_IP_SRC_MASK: case O_IP_SRC_ME: + case O_IP4_SRC_ME: case O_IP_SRC_SET: show_prerequisites(&flags, HAVE_PROTO, 0); if (!(flags & HAVE_SRCIP)) @@ -1202,6 +1207,7 @@ case O_IP_DST_LOOKUP: case O_IP_DST_MASK: case O_IP_DST_ME: + case O_IP4_DST_ME: case O_IP_DST_SET: show_prerequisites(&flags, HAVE_PROTO|HAVE_SRCIP, 0); if (!(flags & HAVE_DSTIP)) @@ -1972,6 +1978,12 @@ return; } + if (strcmp(av, "me4") == 0) { + cmd->o.opcode = O_IP4_DST_ME; + cmd->o.len |= F_INSN_SIZE(ipfw_insn); + return; + } + if (strncmp(av, "table(", 6) == 0) { char *p = strchr(av + 6, ','); @@ -2478,6 +2490,8 @@ cmd->opcode = O_IP_SRC_SET; else if (cmd->opcode == O_IP_DST_LOOKUP) /* table */ cmd->opcode = O_IP_SRC_LOOKUP; + else if (cmd->opcode == O_IP4_DST_ME) /* me4 */ + cmd->opcode = O_IP4_SRC_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn)) /* me */ cmd->opcode = O_IP_SRC_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn_u32)) /* one IP */ @@ -2495,6 +2509,8 @@ ; else if (cmd->opcode == O_IP_DST_LOOKUP) /* table */ ; + else if (cmd->opcode == O_IP4_DST_ME) /* me4 */ + ; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn)) /* me */ cmd->opcode = O_IP_DST_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn_u32)) /* one IP */ @@ -2534,7 +2550,7 @@ ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a))) + strcmp(av, "me4") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_srcip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; @@ -2560,7 +2576,7 @@ ret = add_dstip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a))) + strcmp(av, "me4") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_dstip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; Index: sys/netinet/ip_fw.h =================================================================== --- sys/netinet/ip_fw.h (revision 200668) +++ sys/netinet/ip_fw.h (working copy) @@ -166,6 +166,8 @@ O_ALTQ, /* u32 = altq classif. qid */ O_DIVERTED, /* arg1=bitmap (1:loop, 2:out) */ O_TCPDATALEN, /* arg1 = tcp data len */ + O_IP4_SRC_ME, /* none */ + O_IP4_DST_ME, /* none */ O_IP6_SRC, /* address without mask */ O_IP6_SRC_ME, /* my addresses */ O_IP6_SRC_MASK, /* address with the mask */ Index: sys/netinet/ipfw/ip_fw2.c =================================================================== --- sys/netinet/ipfw/ip_fw2.c (revision 200668) +++ sys/netinet/ipfw/ip_fw2.c (working copy) @@ -1444,12 +1444,22 @@ break; case O_IP_SRC_ME: + case O_IP4_SRC_ME: if (is_ipv4) { struct ifnet *tif; INADDR_TO_IFP(src_ip, tif); match = (tif != NULL); + break; } + if (cmd->opcode == O_IP4_SRC_ME) + break; + /* FALLTHROUGH */ +#ifdef INET6 + case O_IP6_SRC_ME: + match = is_ipv6 && + search_ip6_addr_net(&args->f_id.src_ip6); +#endif break; case O_IP_DST_SET: @@ -1477,12 +1487,22 @@ break; case O_IP_DST_ME: + case O_IP4_DST_ME: if (is_ipv4) { struct ifnet *tif; INADDR_TO_IFP(dst_ip, tif); match = (tif != NULL); + break; } + if (cmd->opcode == O_IP4_DST_ME) + break; + /* FALLTHROUGH */ +#ifdef INET6 + case O_IP6_DST_ME: + match = is_ipv6 && + search_ip6_addr_net(&args->f_id.dst_ip6); +#endif break; case O_IP_SRCPORT: @@ -1750,14 +1770,6 @@ } break; - case O_IP6_SRC_ME: - match= is_ipv6 && search_ip6_addr_net(&args->f_id.src_ip6); - break; - - case O_IP6_DST_ME: - match= is_ipv6 && search_ip6_addr_net(&args->f_id.dst_ip6); - break; - case O_FLOW6ID: match = is_ipv6 && flow6id_match(args->f_id.flow_id6, Index: sys/netinet/ipfw/ip_fw_sockopt.c =================================================================== --- sys/netinet/ipfw/ip_fw_sockopt.c (revision 200668) +++ sys/netinet/ipfw/ip_fw_sockopt.c (working copy) @@ -536,6 +536,8 @@ case O_VERSRCREACH: case O_ANTISPOOF: case O_IPSEC: + case O_IP4_SRC_ME: + case O_IP4_DST_ME: #ifdef INET6 case O_IP6_SRC_ME: case O_IP6_DST_ME: --Multipart_Sat_Dec_19_00:45:23_2009-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sat_Dec_19_00:45:23_2009-1--