From owner-freebsd-ipfw@FreeBSD.ORG Sun Sep 2 13:38:48 2007 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E5E16A419; Sun, 2 Sep 2007 13:38:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB5C13C457; Sun, 2 Sep 2007 13:38:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l82DcmJE098395; Sun, 2 Sep 2007 13:38:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l82DcmQT098391; Sun, 2 Sep 2007 13:38:48 GMT (envelope-from linimon) Date: Sun, 2 Sep 2007 13:38:48 GMT Message-Id: <200709021338.l82DcmQT098391@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/116009: [ipfw] [patch] Ignore errors when loading ruleset from file + rule replacement command 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: Sun, 02 Sep 2007 13:38:48 -0000 Old Synopsis: Ignore errors when loading ruleset from file + rule replacement command New Synopsis: [ipfw] [patch] Ignore errors when loading ruleset from file + rule replacement command Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 2 13:36:59 UTC 2007 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=116009 From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 04:31:50 2007 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 429E616A418 for ; Mon, 3 Sep 2007 04:31:50 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id DC26D13C45A for ; Mon, 3 Sep 2007 04:31:49 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DC7CD182A6 for ; Mon, 3 Sep 2007 16:31:27 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTZrroGUyuwD for ; Mon, 3 Sep 2007 16:31:27 +1200 (NZST) Received: from bluebottle.insec.auckland.ac.nz (bluebottle.insec.auckland.ac.nz [130.216.4.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A703B18367 for ; Mon, 3 Sep 2007 16:31:27 +1200 (NZST) Message-ID: <46DB8E20.8070404@auckland.ac.nz> Date: Mon, 03 Sep 2007 16:31:28 +1200 From: Russell Fulton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Problems with pipes... 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, 03 Sep 2007 04:31:50 -0000 Hi I'm having problems getting pipes to work in ipfw (under free bsd). First a little background that will explain why some of the stuff in here is there. We have a wireless lan with two firewalls which fail over using carp. There are several different SSIDs which appear to the firewall as different vlans. I am working on the 'backup' firewall and we have set up a test ssid/vlan 130.216.155.0/24) which has this firewall as primary. I have to leave the carp rules in for the other vlans otherwise carp gets all confused :) and the backup fw suddenly thinks is is primary for everything (been there done that ;) I have cut the rule set down as much as I can: # already established connections continue going through add 10 check-state # allow outbond traffic to mailhost from UoA add 11 allow tcp from 130.216.89.0/24, 130.216.90.0/23 to 130.216.11.210 25, 587, 465 xmit fxp1 setup keep-state # bad ports that we want to block add 15 deny log logamount 0 udp from any to any 7,67,68,69,111,134-140,199,445,512,513,520,1993,2049,1900,5000 via fxp1 add 16 deny log logamount 0 tcp from any to any 7,11,15,25,67,68,87,111,134-140,144,199,445,511-514,1025,1993,1900,2049,2766,5000,5999-6020 via fxp1 # carp VRP add 20 allow all from 130.216.89.6/31 to 224.0.0.18 via vlan89 add 21 allow all from 130.216.90.6/31 to 224.0.0.18 via vlan90 add 22 allow all from 130.216.94.6/31 to 224.0.0.18 via vlan94 add 23 allow all from 130.216.95.6/31 to 224.0.0.18 via vlan95 add 24 allow all from 130.216.1.11 to 224.0.0.18 via fxp1 add 24 allow all from 130.216.1.12 to 224.0.0.18 via fxp1 add 30 allow all from 130.216.4.173 to 224.0.0.18 via fxp1 add 31 allow all from 130.216.4.174 to 224.0.0.18 via fxp1 add 40 allow tcp from 130.216.4.0/23, 130.216.76.0/23 to any in recv fxp1 setup keep-state # allow anything else in from the vlans add 01139 allow all from 130.216.155.0/24 to any in recv vlan155 # Allow it all out fxp1 add 01145 allow tcp from 130.216.89.0/24, 130.216.90.0/23,130.216.94.0/24,130.216.95.0/24, 130.216.155.0/24 to any out via fxp1 setup keep-state add 01147 allow all from 130.216.89.0/24, 130.216.90.0/23,130.216.94.0/24,130.216.95.0/24, 130.216.155.0/24 to any out xmit fxp1 keep-state # don't forget the loopback interface or some things might break add 01102 allow all from any to any via lo0 setup keep-state # test vlan 155 pipe 15 config mask src-ip 0x000000ff bw 128Kbit/s add 02420 pipe 15 all from 130.216.155.0/24 to any add 06000 deny log logamount 0 all from any to any ################################################# here is a ipfw -d show during a file transfer [root@wgate-1 /root]# ipfw -d show 00010 0 0 check-state 00011 0 0 allow tcp from 130.216.89.0/24,130.216.90.0/23 to 130.216.11.210 dst-port 25,587,465 xmit fxp1 setup keep-state 00015 0 0 deny log udp from any to any dst-port 7,67,68,69,111,134-140,199,445,512,513,520,1993,2049,1900,5000 via fxp1 00016 0 0 deny log tcp from any to any dst-port 7,11,15,25,67,68,87,111,134-140,144,199,445,511-514,1025,1993,1900,2049,2766,5000,5999-6020 via fxp1 00020 115 6440 allow ip from 130.216.89.6/31 to 224.0.0.18 via vlan89 00021 114 6384 allow ip from 130.216.90.6/31 to 224.0.0.18 via vlan90 00022 114 6384 allow ip from 130.216.94.6/31 to 224.0.0.18 via vlan94 00023 115 6440 allow ip from 130.216.95.6/31 to 224.0.0.18 via vlan95 00024 0 0 allow ip from 130.216.1.11 to 224.0.0.18 via fxp1 00024 115 6440 allow ip from 130.216.1.12 to 224.0.0.18 via fxp1 00030 0 0 allow ip from 130.216.4.173 to 224.0.0.18 via fxp1 00031 0 0 allow ip from 130.216.4.174 to 224.0.0.18 via fxp1 00040 358 36699 allow tcp from 130.216.4.0/23,130.216.76.0/23 to any in recv fxp1 setup keep-state 01102 0 0 allow ip from any to any via lo0 setup keep-state 01139 1 48 allow ip from 130.216.155.0/24 to any in recv vlan155 01145 11271 9865040 allow tcp from 130.216.89.0/24,130.216.90.0/23,130.216.94.0/24,130.216.95.0/24,130.216.155.0/24 to any out via fxp1 setup keep-state 01147 0 0 allow ip from 130.216.89.0/24,130.216.90.0/23,130.216.94.0/24,130.216.95.0/24,130.216.155.0/24 to any out xmit fxp1 keep-state 02420 0 0 pipe 15 ip from 130.216.155.0/24 to any 06000 201 25058 deny log ip from any to any 65535 160 74420 deny ip from any to any ## Dynamic rules (2): 01145 11270 9864992 (300s) STATE tcp 130.216.155.13 1525 <-> 161.53.24.9 80 00040 357 36635 (300s) STATE tcp 130.216.4.12 60906 <-> 130.216.1.11 22 Note that nothing is going through pipe 15 even thought it would appear to match dynamic rule 01145. What have I screwed up? Russell. From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 11:08:12 2007 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 7307716A468 for ; Mon, 3 Sep 2007 11:08:12 +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 5A79713C481 for ; Mon, 3 Sep 2007 11:08:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l83B8Cf4079084 for ; Mon, 3 Sep 2007 11:08:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l83B89HQ079080 for freebsd-ipfw@FreeBSD.org; Mon, 3 Sep 2007 11:08:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2007 11:08:09 GMT Message-Id: <200709031108.l83B89HQ079080@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 you 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, 03 Sep 2007 11:08:12 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw ipfw is seems to be broken to limit number of connecti o kern/115261 ipfw [ipfw]: incorrect 'ipfw: pullup failed' with IPv6 no-n 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 27 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 16:48:34 2007 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 01EA116A417 for ; Mon, 3 Sep 2007 16:48:34 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail15.mail.yandex.net (webmail15.mail.yandex.net [213.180.200.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1B99913C478 for ; Mon, 3 Sep 2007 16:48:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail15) by mail.yandex.ru id S315915AbXICQsG for (+ 2 others); Mon, 3 Sep 2007 20:48:06 +0400 X-Yandex-Spam: 1 Received: from [77.72.136.71] ([77.72.136.71]) by mail.yandex.ru with HTTP; Mon, 03 Sep 2007 20:48:03 +0400 From: "Andrey V. Elsukov" To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Message-Id: <1261981188838083@webmail15.yandex.ru> Date: Mon, 03 Sep 2007 20:48:03 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Type: multipart/mixed; boundary="----==--bound.126199.webmail15.yandex.ru" Cc: andre@freebsd.org, rwatson@freebsd.org Subject: Re: dummynet / ipfw2: panic, double fault 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, 03 Sep 2007 16:48:34 -0000 ------==--bound.126199.webmail15.yandex.ru Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi, I got a trace for this fault. dummynet reinject packet to the ip_input through netisr_dispath. This procedure was done success several times, but in the next time it's fault. (kgdb) p &ipfw_chk $1 = (int (*)(struct ip_fw_args *)) 0xc3374ea0 (kgdb) l *(0xc3374ea0+0x16) 0xc3374eb6 is in ipfw_chk (/usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2304). 2299 * ip is the beginning of the ip(4 or 6) header. 2300 * Calculated by adding the L3offset to the start of data. 2301 * (Until we start using L3offset, the packet is 2302 * supposed to start with the ip header). 2303 */ 2304 struct mbuf *m = args->m; 2305 struct ip *ip = mtod(m, struct ip *); 2306 2307 /* 2308 * For rules which contain uid/gid or jail constraints, cache I don't understand why we have panic here.. Can someone explain this panic? -- WBR, Andrey V. Elsukov ------==--bound.126199.webmail15.yandex.ru Content-Disposition: attachment; filename="log.txt" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="log.txt" RmF0YWwgZG91YmxlIGZhdWx0OgplaXAgPSAweGMzMzQzZWI2CmVzcCA9IDB4ZDRmODBmN2MKZWJw ID0gMHhkNGY4MTI3YwpjcHVpZCA9IDA7IGFwaWMgaWQgPSAwMApwYW5pYzogZG91YmxlIGZhdWx0 CmNwdWlkID0gMApLREI6IGVudGVyOiBwYW5pYwpbdGhyZWFkIHBpZCAzMyB0aWQgMTAwMDM3IF0K U3RvcHBlZCBhdCAgICAgIGtkYl9lbnRlcisweDMyOiBsZWF2ZQpkYj4gYnQKVHJhY2luZyBwaWQg MzMgdGlkIDEwMDAzNyB0ZCAweGMyZWNlNDAwCmtkYl9lbnRlcihjMGE4YTBkYywwLGMwYWI2Zjll LGMwYzA2Y2IwLDAsLi4uKSBhdCBrZGJfZW50ZXIrMHgzMgpwYW5pYyhjMGFiNmY5ZSwwLDAsMCww LC4uLikgYXQgcGFuaWMrMHgxMjQKZGJsZmF1bHRfaGFuZGxlcigpIGF0IGRibGZhdWx0X2hhbmRs ZXIrMHg5YgotLS0gdHJhcCAweDE3LCBlaXAgPSAweGMzMzQzZWI2LCBlc3AgPSAweGQ0ZjgwZjdj LCBlYnAgPSAweGQ0ZjgxMjdjIC0tLQppcGZ3X2NoayhkNGY4MTI5NCw0MWVjMGQ3ZSwwLDAsYzMw ZGUwMDAsLi4uKSBhdCBpcGZ3X2NoaysweDE2CmlwZndfY2hlY2tfaW4oMCxkNGY4MTM5OCxjMmVh ZTgwMCwxLDAsLi4uKSBhdCBpcGZ3X2NoZWNrX2luKzB4ZDcKcGZpbF9ydW5faG9va3MoYzBiZTll MDAsZDRmODEzZWMsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAoKaXBf aW5wdXQoYzMwZGUwMDAsYzJlY2U0OTgsYzBiM2I3NjQsYzMzN2FiMDYsYzMwZGUwMDAsLi4uKSBh dCBpcF9pbnB1dCsweDI0ZApuZXRpc3JfZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywxLGMw YTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRfc2VuZChjMzM3Y2Iy YywwLGMzMzdhYjA2LDU2MCxjZiwuLi4pIGF0IGR1bW15bmV0X3NlbmQrMHgxMzYKZHVtbXluZXRf aW8oYzMwZGUwMDAsMixkNGY4MTRmYywwLGMzMGRlMDAwLC4uLikgYXQgZHVtbXluZXRfaW8rMHgz NzMKaXBmd19jaGVja19pbigwLGQ0ZjgxNjAwLGMyZWFlODAwLDEsMCwuLi4pIGF0IGlwZndfY2hl Y2tfaW4rMHgyMjAKcGZpbF9ydW5faG9va3MoYzBiZTllMDAsZDRmODE2NTQsYzJlYWU4MDAsMSww LC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAoKaXBfaW5wdXQoYzMwZGUwMDAsYzJlY2U0OTgs YzBiM2I3NjQsYzMzN2FiMDYsYzMwZGUwMDAsLi4uKSBhdCBpcF9pbnB1dCsweDI0ZApuZXRpc3Jf ZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rp c3BhdGNoKzB4NzMKZHVtbXluZXRfc2VuZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2MCxjZiwuLi4p IGF0IGR1bW15bmV0X3NlbmQrMHgxMzYKZHVtbXluZXRfaW8oYzMwZGUwMDAsMixkNGY4MTc2NCww LGMzMGRlMDAwLC4uLikgYXQgZHVtbXluZXRfaW8rMHgzNzMKaXBmd19jaGVja19pbigwLGQ0Zjgx ODY4LGMyZWFlODAwLDEsMCwuLi4pIGF0IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5faG9v a3MoYzBiZTllMDAsZDRmODE4YmMsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3Mr MHg4OAoKaXBfaW5wdXQoYzMwZGUwMDAsYzJlY2U0OTgsYzBiM2I3NjQsYzMzN2FiMDYsYzMwZGUw MDAsLi4uKSBhdCBpcF9pbnB1dCsweDI0ZApuZXRpc3JfZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3 Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRfc2Vu ZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2MCxjZiwuLi4pIGF0IGR1bW15bmV0X3NlbmQrMHgxMzYK ZHVtbXluZXRfaW8oYzMwZGUwMDAsMixkNGY4MTljYywwLGMzMGRlMDAwLC4uLikgYXQgZHVtbXlu ZXRfaW8rMHgzNzMKaXBmd19jaGVja19pbigwLGQ0ZjgxYWQwLGMyZWFlODAwLDEsMCwuLi4pIGF0 IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5faG9va3MoYzBiZTllMDAsZDRmODFiMjQsYzJl YWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAoKaXBfaW5wdXQoYzMwZGUwMDAs YzJlY2U0OTgsYzBiM2I3NjQsYzMzN2FiMDYsYzMwZGUwMDAsLi4uKSBhdCBpcF9pbnB1dCsweDI0 ZApuZXRpc3JfZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQg bmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRfc2VuZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2 MCxjZiwuLi4pIGF0IGR1bW15bmV0X3NlbmQrMHgxMzYKZHVtbXluZXRfaW8oYzMwZGUwMDAsMixk NGY4MWMzNCwwLGMzMGRlMDAwLC4uLikgYXQgZHVtbXluZXRfaW8rMHgzNzMKaXBmd19jaGVja19p bigwLGQ0ZjgxZDM4LGMyZWFlODAwLDEsMCwuLi4pIGF0IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZp bF9ydW5faG9va3MoYzBiZTllMDAsZDRmODFkOGMsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9y dW5faG9va3MrMHg4OAoKaXBfaW5wdXQoYzMwZGUwMDAsYzJlY2U0OTgsYzBiM2I3NjQsYzMzN2Fi MDYsYzMwZGUwMDAsLi4uKSBhdCBpcF9pbnB1dCsweDI0ZApuZXRpc3JfZGlzcGF0Y2goMixjMzBk ZTAwMCxjMzM3Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVt bXluZXRfc2VuZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2MCxjZiwuLi4pIGF0IGR1bW15bmV0X3Nl bmQrMHgxMzYKZHVtbXluZXRfaW8oYzMwZGUwMDAsMixkNGY4MWU5YywwLGMzMGRlMDAwLC4uLikg YXQgZHVtbXluZXRfaW8rMHgzNzMKaXBmd19jaGVja19pbigwLGQ0ZjgxZmEwLGMyZWFlODAwLDEs MCwuLi4pIGF0IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5faG9va3MoYzBiZTllMDAsZDRm ODFmZjQsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAoKaXBfaW5wdXQo YzMwZGUwMDAsYzJlY2U0OTgsYzBiM2I3NjQsYzMzN2FiMDYsYzMwZGUwMDAsLi4uKSBhdCBpcF9p bnB1dCsweDI0ZApuZXRpc3JfZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywxLGMwYTg4ZTNk LC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRfc2VuZChjMzM3Y2IyYywwLGMz MzdhYjA2LDU2MCxjZiwuLi4pIGF0IGR1bW15bmV0X3NlbmQrMHgxMzYKZHVtbXluZXRfaW8oYzMw ZGUwMDAsMixkNGY4MjEwNCwwLGMzMGRlMDAwLC4uLikgYXQgZHVtbXluZXRfaW8rMHgzNzMKaXBm d19jaGVja19pbigwLGQ0ZjgyMjA4LGMyZWFlODAwLDEsMCwuLi4pIGF0IGlwZndfY2hlY2tfaW4r MHgyMjAKcGZpbF9ydW5faG9va3MoYzBiZTllMDAsZDRmODIyNWMsYzJlYWU4MDAsMSwwLC4uLikg YXQgcGZpbF9ydW5faG9va3MrMHg4OAoKaXBfaW5wdXQoYzMwZGUwMDAsYzJlY2U0OTgsYzBiM2I3 NjQsYzMzN2FiMDYsYzMwZGUwMDAsLi4uKSBhdCBpcF9pbnB1dCsweDI0ZApuZXRpc3JfZGlzcGF0 Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNo KzB4NzMKZHVtbXluZXRfc2VuZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2MCxjZiwuLi4pIGF0IGR1 bW15bmV0X3NlbmQrMHgxMzYKZHVtbXluZXRfaW8oYzMwZGUwMDAsMixkNGY4MjM2YywwLGMzMGRl MDAwLC4uLikgYXQgZHVtbXluZXRfaW8rMHgzNzMKaXBmd19jaGVja19pbigwLGQ0ZjgyNDcwLGMy ZWFlODAwLDEsMCwuLi4pIGF0IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5faG9va3MoYzBi ZTllMDAsZDRmODI0YzQsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAoK aXBfaW5wdXQoYzMwZGUwMDAsYzJlY2U0OTgsYzBiM2I3NjQsYzMzN2FiMDYsYzMwZGUwMDAsLi4u KSBhdCBpcF9pbnB1dCsweDI0ZApuZXRpc3JfZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywx LGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRfc2VuZChjMzM3 Y2IyYywwLGMzMzdhYjA2LDU2MCxjZiwuLi4pIGF0IGR1bW15bmV0X3NlbmQrMHgxMzYKZHVtbXlu ZXRfaW8oYzMwZGUwMDAsMixkNGY4MjVkNCwwLGMzMGRlMDAwLC4uLikgYXQgZHVtbXluZXRfaW8r MHgzNzMKaXBmd19jaGVja19pbigwLGQ0ZjgyNmQ4LGMyZWFlODAwLDEsMCwuLi4pIGF0IGlwZndf Y2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5faG9va3MoYzBiZTllMDAsZDRmODI3MmMsYzJlYWU4MDAs MSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAppcF9pbnB1dChjMzBkZTAwMCxjMmVjZTQ5 OCxjMGIzYjc2NCxjMzM3YWIwNixjMzBkZTAwMCwuLi4pIGF0IGlwX2lucHV0KzB4MjRkCgpuZXRp c3JfZGlzcGF0Y2goMixjMzBkZTAwMCxjMzM3Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNy X2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRfc2VuZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2MCxjZiwu Li4pIGF0IGR1bW15bmV0X3NlbmQrMHgxMzYKZHVtbXluZXRfaW8oYzMwZGUwMDAsMixkNGY4Mjgz YywwLGMzMGRlMDAwLC4uLikgYXQgZHVtbXluZXRfaW8rMHgzNzMKaXBmd19jaGVja19pbigwLGQ0 ZjgyOTQwLGMyZWFlODAwLDEsMCwuLi4pIGF0IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5f aG9va3MoYzBiZTllMDAsZDRmODI5OTQsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9v a3MrMHg4OAppcF9pbnB1dChjMzBkZTAwMCxjMmVjZTQ5OCxjMGIzYjc2NCxjMzM3YWIwNixjMzBk ZTAwMCwuLi4pIGF0IGlwX2lucHV0KzB4MjRkCgpuZXRpc3JfZGlzcGF0Y2goMixjMzBkZTAwMCxj MzM3Y2IyYywxLGMwYTg4ZTNkLC4uLikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZHVtbXluZXRf c2VuZChjMzM3Y2IyYywwLGMzMzdhYjA2LDU2MCxjMDllMzExNSwuLi4pIGF0IGR1bW15bmV0X3Nl bmQrMHgxMzYKZHVtbXluZXRfaW8oYzMwZGUwMDAsMixkNGY4MmFhNCwwLGMzMGRlMDAwLC4uLikg YXQgZHVtbXluZXRfaW8rMHgzNzMKaXBmd19jaGVja19pbigwLGQ0ZjgyYmE4LGMyZWFlODAwLDEs MCwuLi4pIGF0IGlwZndfY2hlY2tfaW4rMHgyMjAKcGZpbF9ydW5faG9va3MoYzBiZTllMDAsZDRm ODJiZmMsYzJlYWU4MDAsMSwwLC4uLikgYXQgcGZpbF9ydW5faG9va3MrMHg4OAppcF9pbnB1dChj MzBkZTAwMCxjMDY1MWEwMiw4MDAsYzJlYWU4MDAsODAwLC4uLikgYXQgaXBfaW5wdXQrMHgyNGQK Cm5ldGlzcl9kaXNwYXRjaCgyLGMzMGRlMDAwLGMyZWNlNDk4LGMwYjNiNzY0LGMwYWE0YjQ2LC4u LikgYXQgbmV0aXNyX2Rpc3BhdGNoKzB4NzMKZXRoZXJfZGVtdXgoYzJlYWU4MDAsYzMwZGUwMDAs MywwLDMsLi4uKSBhdCBldGhlcl9kZW11eCsweDFmMQpldGhlcl9pbnB1dChjMmVhZTgwMCxjMzBk ZTAwMCxjMGFhNGI0Niw0YjIsMCwuLi4pIGF0IGV0aGVyX2lucHV0KzB4MzdmCnJsX3J4ZW9mKGMy ZTk5Y2Q0LDAsYzBhYTRiNDYsNTNjLGMyZTk5Y2Q0LC4uLikgYXQgcmxfcnhlb2YrMHgyNDQKcmxf aW50cihjMmU5OTgwMCwwLGMwYTg2Y2U1LDQ3MSxjMmRiMjU2NCwuLi4pIGF0IHJsX2ludHIrMHg5 YwppdGhyZWFkX2xvb3AoYzJlZGMyMTAsZDRmODJkMzgsYzBhODZhNTksMzE1LGMyZWQwNTU4LC4u LikgYXQgaXRocmVhZF9sb29wKzB4MWI1CmZvcmtfZXhpdChjMDcyZWQ3MCxjMmVkYzIxMCxkNGY4 MmQzOCkgYXQgZm9ya19leGl0KzB4YjgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lKzB4OAotLS0gdHJhcCAwLCBlaXAgPSAwLCBlc3AgPSAweGQ0ZjgyZDcwLCBlYnAgPSAwIC0t LQo= ------==--bound.126199.webmail15.yandex.ru-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 17:50:43 2007 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 8F28516A418 for ; Mon, 3 Sep 2007 17:50:43 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id E490B13C4CB for ; Mon, 3 Sep 2007 17:50:42 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id E988E10527F; Tue, 4 Sep 2007 00:50:39 +0700 (NOVST) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nZhbuQyMhKD; Tue, 4 Sep 2007 00:50:38 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 9516C10527E; Tue, 4 Sep 2007 00:50:38 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 00:50:38 +0700 Received: from nuclight.avtf.net ([83.172.2.158]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 00:50:38 +0700 To: "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org References: <1261981188838083@webmail15.yandex.ru> Message-ID: Date: Tue, 04 Sep 2007 00:50:36 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <1261981188838083@webmail15.yandex.ru> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 03 Sep 2007 17:50:38.0180 (UTC) FILETIME=[EFD52240:01C7EE52] Cc: Subject: Re: dummynet / ipfw2: panic, double fault 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, 03 Sep 2007 17:50:43 -0000 03.09.07 @ 23:48 Andrey V. Elsukov wrote: > I got a trace for this fault. > dummynet reinject packet to the ip_input through netisr_dispath. > This procedure was done success several times, but in the next time > it's fault. > (kgdb) p &ipfw_chk > $1 = (int (*)(struct ip_fw_args *)) 0xc3374ea0 > (kgdb) l *(0xc3374ea0+0x16) > 0xc3374eb6 is in ipfw_chk > (/usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2304). > 2299 * ip is the beginning of the ip(4 or 6) header. > 2300 * Calculated by adding the L3offset to the start > of data. > 2301 * (Until we start using L3offset, the packet is > 2302 * supposed to start with the ip header). > 2303 */ > 2304 struct mbuf *m = args->m; > 2305 struct ip *ip = mtod(m, struct ip *); > > I don't understand why we have panic here.. > Can someone explain this panic? We have repeating groups of calls for several times, ending in: > dblfault_handler() at dblfault_handler+0x9b > --- trap 0x17, eip = 0xc3343eb6, esp = 0xd4f80f7c, ebp = 0xd4f8127c --- > ipfw_chk(d4f81294,41ec0d7e,0,0,c30de000,...) at ipfw_chk+0x16 As we can see from comment in /sys/i386/i386/trap.c: * Double fault handler. Called when a fault occurs while writing * a frame for a trap/exception onto the stack. This usually occurs * when the stack overflows (such is the case with infinite recursion, * for example). That's look like our case, repeating calls, as in infinite recursion. I suppose that interrupt thread's stack in the kernel is too small for this case. Quick-n-dirty hackish solution could be increasing stack size, but that could be overriden by another bunch of rules. Alas, I am not a VM/netisr guru to find the right way... -- WBR, Vadim Goncharov From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 18:11:11 2007 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 64C0116A419 for ; Mon, 3 Sep 2007 18:11:11 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id C2F0113C457 for ; Mon, 3 Sep 2007 18:11:10 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 6445910527F; Tue, 4 Sep 2007 01:11:09 +0700 (NOVST) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7nBHY9iarmM; Tue, 4 Sep 2007 01:11:08 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 4C92B10527E; Tue, 4 Sep 2007 01:11:08 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:11:08 +0700 Received: from nuclight.avtf.net ([83.172.2.158]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:11:08 +0700 To: "Russell Fulton" , freebsd-ipfw@freebsd.org References: <46D76443.80407@auckland.ac.nz> Message-ID: Date: Tue, 04 Sep 2007 01:11:06 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46D76443.80407@auckland.ac.nz> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 03 Sep 2007 18:11:08.0149 (UTC) FILETIME=[CCF38250:01C7EE55] Cc: Subject: Re: beginners questions 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, 03 Sep 2007 18:11:11 -0000 31.08.07 @ 07:43 Russell Fulton wrote: > Before you ask, yes I've RTFM ;) which was very imformative and there > are still some things that I have missed. > > 1/ Is there a way of reloading rules while maintaining the state table > or is this the default? (put another way does flush affect dynamic > rules). Yes, it flushes dynamic rules because they depend on their parents, which are flushed too. > 2/ we are using state and also shaping traffic via pipes. What > interaction, if any is there between pipes and state? i.e. if a packet > gets sent to a pipe will other traffic that is matched by the dynamic > rule also get sent to the pipe? Yes, it should. > 3/ are pipes bidirectional? I.e. do I need to say > > add 02421 pipe 6 all from 130.216.95.0/24 to any > add 02422 pipe 7 all from any to 130.216.95.0/24 Umm... that depends on what you really want. Pipe is unidirectional in sense that you always send packets into one end, and they'll get out from the other end. So speed is depends on where that ends are connected to. So if you are configuring pipe to, e.g., 1 Mbit, and say "pipe 1 all from A to B" and "pipe 1 all from B to A", then both upload+download between A and B will be 1 Mbit, SUMMARY. And if you send "A to B" traffic into 512 Kbit pipe and "B to A" traffic into 128 Kbit pipe, than you'll get exactly this speed, in specified directions, respectively. -- WBR, Vadim Goncharov From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 18:19:46 2007 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 31B6F16A417 for ; Mon, 3 Sep 2007 18:19:46 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id CC8B813C45A for ; Mon, 3 Sep 2007 18:19:45 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id C203F1051AA; Tue, 4 Sep 2007 01:19:44 +0700 (NOVST) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t62lgrBekQTs; Tue, 4 Sep 2007 01:19:43 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 79EA110527E; Tue, 4 Sep 2007 01:19:43 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:19:43 +0700 Received: from nuclight.avtf.net ([83.172.2.158]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:19:43 +0700 Date: Tue, 04 Sep 2007 01:19:41 +0700 To: "Russell Fulton" References: <46D66176.9020300@auckland.ac.nz> <46D70145.3030708@auckland.ac.nz> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <46D70145.3030708@auckland.ac.nz> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 03 Sep 2007 18:19:43.0227 (UTC) FILETIME=[FFF62CB0:01C7EE56] Cc: freebsd-ipfw@freebsd.org Subject: Re: getting state to work properly 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, 03 Sep 2007 18:19:46 -0000 31.08.07 @ 00:41 Russell Fulton wrote: > Rule set appended -- anonymizing the rule set while keeping the sense > would be a lot of work and I don't want to trim it down for fear of > dropping something vital. As this network is not exposed to the > internet and the firewall's primary purpose is traffic shaping not > security I'll post it. > > Attached. Some summary points: 1) localhost traffic should be unconditionally allowed at the start of firewall, state here is useless. 2) antispoofing can be more clearly done with antispoof and verrevpath keywords. Like: ipfw add 100 pass all from any to any via lo0 ipfw add 110 deny all from any to any in recv $extiface not verrevpath ipfw add 111 deny log all from any to any in recv $intiface not antispoof ipfw add 112 check-state 3) Using "setup" option while protocol is "all" is unclear - it will match only tcp, while you possibly ment to keep-state on every protocol, not just tcp. 4) Consider using sysctl net.inet.ip.fw.one_pass - it controls whether traffic after getting out from pipe will continue go through ipfw ruleset. 5) Don't forget that ipfw has two passes, input and output, so if you are sending traffic from A to B into pipe without "in" or "out" options, speed will be half of that specified in a pipe. -- WBR, Vadim Goncharov From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 18:24:43 2007 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 6652816A418 for ; Mon, 3 Sep 2007 18:24:43 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id BB82313C461 for ; Mon, 3 Sep 2007 18:24:42 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 53EA810527F; Tue, 4 Sep 2007 01:24:41 +0700 (NOVST) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmbOgI6yxBIb; Tue, 4 Sep 2007 01:24:39 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id EB1D51051AA; Tue, 4 Sep 2007 01:24:39 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:24:40 +0700 Received: from nuclight.avtf.net ([83.172.2.158]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 01:24:39 +0700 Date: Tue, 04 Sep 2007 01:24:38 +0700 To: "Russell Fulton" , freebsd-ipfw@freebsd.org References: <46DB8E20.8070404@auckland.ac.nz> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <46DB8E20.8070404@auckland.ac.nz> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 03 Sep 2007 18:24:39.0805 (UTC) FILETIME=[B0BC62D0:01C7EE57] Cc: Subject: Re: Problems with pipes... 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, 03 Sep 2007 18:24:43 -0000 03.09.07 @ 11:31 Russell Fulton wrote: > here is a ipfw -d show during a file transfer > > [root@wgate-1 /root]# ipfw -d show > 00010 0 0 check-state > 00011 0 0 allow tcp from 130.216.89.0/24,130.216.90.0/23 to > 130.216.11.210 dst-port 25,587,465 xmit fxp1 setup keep-state > 00015 0 0 deny log udp from any to any dst-port > 7,67,68,69,111,134-140,199,445,512,513,520,1993,2049,1900,5000 via fxp1 > 00016 0 0 deny log tcp from any to any dst-port > 7,11,15,25,67,68,87,111,134-140,144,199,445,511-514,1025,1993,1900,2049,2766,5000,5999-6020 > via fxp1 > 00020 115 6440 allow ip from 130.216.89.6/31 to 224.0.0.18 via > vlan89 > 00021 114 6384 allow ip from 130.216.90.6/31 to 224.0.0.18 via > vlan90 > 00022 114 6384 allow ip from 130.216.94.6/31 to 224.0.0.18 via > vlan94 > 00023 115 6440 allow ip from 130.216.95.6/31 to 224.0.0.18 via > vlan95 > 00024 0 0 allow ip from 130.216.1.11 to 224.0.0.18 via fxp1 > 00024 115 6440 allow ip from 130.216.1.12 to 224.0.0.18 via fxp1 > 00030 0 0 allow ip from 130.216.4.173 to 224.0.0.18 via fxp1 > 00031 0 0 allow ip from 130.216.4.174 to 224.0.0.18 via fxp1 > 00040 358 36699 allow tcp from 130.216.4.0/23,130.216.76.0/23 to any > in recv fxp1 setup keep-state > 01102 0 0 allow ip from any to any via lo0 setup keep-state > 01139 1 48 allow ip from 130.216.155.0/24 to any in recv vlan155 > 01145 11271 9865040 allow tcp from > 130.216.89.0/24,130.216.90.0/23,130.216.94.0/24,130.216.95.0/24,130.216.155.0/24 > to any out via fxp1 setup keep-state > 01147 0 0 allow ip from > 130.216.89.0/24,130.216.90.0/23,130.216.94.0/24,130.216.95.0/24,130.216.155.0/24 > to any out xmit fxp1 keep-state > 02420 0 0 pipe 15 ip from 130.216.155.0/24 to any > 06000 201 25058 deny log ip from any to any > 65535 160 74420 deny ip from any to any > ## Dynamic rules (2): > 01145 11270 9864992 (300s) STATE tcp 130.216.155.13 1525 <-> 161.53.24.9 > 80 > 00040 357 36635 (300s) STATE tcp 130.216.4.12 60906 <-> 130.216.1.11 > 22 > > Note that nothing is going through pipe 15 even thought it would appear > to match dynamic rule 01145. > > What have I screwed up? You forgot that *first* matching rule is applied to packet, and then packet don't go to next rules (except "count" action and some other cases). So your packets are matched by 01145 and are allowed to go through your machine, not reaching rule 02420, which is next in the list. -- WBR, Vadim Goncharov From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 3 19:43:47 2007 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 3219E16A417 for ; Mon, 3 Sep 2007 19:43:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id E0A0813C469 for ; Mon, 3 Sep 2007 19:43:46 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l83JA1iS034484; Mon, 3 Sep 2007 12:10:01 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l83JA1xw034483; Mon, 3 Sep 2007 12:10:01 -0700 (PDT) (envelope-from rizzo) Date: Mon, 3 Sep 2007 12:10:01 -0700 From: Luigi Rizzo To: Vadim Goncharov Message-ID: <20070903121001.B34240@xorpc.icir.org> References: <1261981188838083@webmail15.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vadimnuclight@tpu.ru on Tue, Sep 04, 2007 at 12:50:36AM +0700 Cc: freebsd-ipfw@freebsd.org, "Andrey V. Elsukov" Subject: Re: dummynet / ipfw2: panic, double fault 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, 03 Sep 2007 19:43:47 -0000 On Tue, Sep 04, 2007 at 12:50:36AM +0700, Vadim Goncharov wrote: > 03.09.07 @ 23:48 Andrey V. Elsukov wrote: > > > I got a trace for this fault. > > dummynet reinject packet to the ip_input through netisr_dispath. > > This procedure was done success several times, but in the next time > > it's fault. ... > As we can see from comment in /sys/i386/i386/trap.c: > > * Double fault handler. Called when a fault occurs while writing > * a frame for a trap/exception onto the stack. This usually occurs > * when the stack overflows (such is the case with infinite recursion, > * for example). > > That's look like our case, repeating calls, as in infinite recursion. I > suppose that interrupt thread's stack in the kernel is too small for this > case. Quick-n-dirty hackish solution could be increasing stack size, but > that could be overriden by another bunch of rules. Alas, I am not a > VM/netisr guru to find the right way... interesting analysis - but if that is the case i don't understand why the netisr_dispatch routine is called recursively instead of waiting for the previous handler (which is the one who makes the 'recursive' call) to terminate - without looking at the code, i would think that there is a lock of some kind to prevent this ? cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Tue Sep 4 10:51:42 2007 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 4D51F16A469 for ; Tue, 4 Sep 2007 10:51:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2C013C46E for ; Tue, 4 Sep 2007 10:51:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 04 Sep 2007 03:51:41 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BC524126261; Tue, 4 Sep 2007 03:51:40 -0700 (PDT) Message-ID: <46DD38BC.30605@elischer.org> Date: Tue, 04 Sep 2007 03:51:40 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Vadim Goncharov References: <46D66176.9020300@auckland.ac.nz> <46D70145.3030708@auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Russell Fulton Subject: Re: getting state to work properly 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: Tue, 04 Sep 2007 10:51:42 -0000 Vadim Goncharov wrote: > 31.08.07 @ 00:41 Russell Fulton wrote: > >> Rule set appended -- anonymizing the rule set while keeping the sense >> would be a lot of work and I don't want to trim it down for fear of >> dropping something vital. As this network is not exposed to the >> internet and the firewall's primary purpose is traffic shaping not >> security I'll post it. >> >> Attached. > > Some summary points: also bear in mind the way that state is done.. it's not documented anywhere but when you do a 'keep-state', the rule that does the keep-state is stored away, and when a "check state" is run, it effectively JUMPS TO the rule that did the keep-state. If the rule contains some action that is not terminal, then EXECUTION CONTINUES at that point!!! for example check-state [...] "some rules" [...] skipto xxx [packet definition] keep state xxx: more rules the first packet will execute all of "some rules" but subsequent packets from thise sessions will skip straight to the skipto. All packets will do the test in the skipto rule, and subsequent rules. > > 1) localhost traffic should be unconditionally allowed at the start of > firewall, state here is useless. > 2) antispoofing can be more clearly done with antispoof and verrevpath > keywords. Like: > > ipfw add 100 pass all from any to any via lo0 > ipfw add 110 deny all from any to any in recv $extiface not verrevpath > ipfw add 111 deny log all from any to any in recv $intiface not antispoof > ipfw add 112 check-state > > 3) Using "setup" option while protocol is "all" is unclear - it will > match only tcp, while you possibly ment to keep-state on every protocol, > not just tcp. > 4) Consider using sysctl net.inet.ip.fw.one_pass - it controls whether > traffic after getting out from pipe will continue go through ipfw ruleset. > 5) Don't forget that ipfw has two passes, input and output, so if you > are sending traffic from A to B into pipe without "in" or "out" options, > speed will be half of that specified in a pipe. > From owner-freebsd-ipfw@FreeBSD.ORG Tue Sep 4 11:20:08 2007 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 040B616A418 for ; Tue, 4 Sep 2007 11:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE90813C46B for ; Tue, 4 Sep 2007 11:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l84BK7fX070762 for ; Tue, 4 Sep 2007 11:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l84BK7Dn070761; Tue, 4 Sep 2007 11:20:07 GMT (envelope-from gnats) Date: Tue, 4 Sep 2007 11:20:07 GMT Message-Id: <200709041120.l84BK7Dn070761@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Julian Elischer Cc: Subject: Re: kern/116009: [ipfw] [patch] Ignore errors when loading ruleset from file + rule replacement command X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Julian Elischer List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 11:20:08 -0000 The following reply was made to PR kern/116009; it has been noted by GNATS. From: Julian Elischer To: bug-followup@FreeBSD.org, alter@alter.org.ua Cc: Subject: Re: kern/116009: [ipfw] [patch] Ignore errors when loading ruleset from file + rule replacement command Date: Tue, 04 Sep 2007 04:06:25 -0700 I added some code already last year to allow ipfw to continue on after some failures if the -q option is in use (especially delete). I certainly do agree that bombing out is a less that optimal behaviour when automatic use is required. From owner-freebsd-ipfw@FreeBSD.ORG Tue Sep 4 20:01:03 2007 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 9C45716A417 for ; Tue, 4 Sep 2007 20:01:03 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id 63E3913C45A for ; Tue, 4 Sep 2007 20:01:02 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C5332480612 for ; Wed, 5 Sep 2007 08:00:57 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73z8UvILDH5k for ; Wed, 5 Sep 2007 08:00:57 +1200 (NZST) Received: from bluebottle.local (unknown [130.216.7.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6906A480610 for ; Wed, 5 Sep 2007 08:00:57 +1200 (NZST) Message-ID: <46DDB975.3050606@auckland.ac.nz> Date: Wed, 05 Sep 2007 08:00:53 +1200 From: Russell Fulton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <46D66176.9020300@auckland.ac.nz> <46D70145.3030708@auckland.ac.nz> <46DD38BC.30605@elischer.org> In-Reply-To: <46DD38BC.30605@elischer.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: getting state to work properly 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: Tue, 04 Sep 2007 20:01:03 -0000 Julian Elischer wrote: > > also bear in mind the way that state is done.. > it's not documented anywhere but when you do a 'keep-state', the rule > that > does the keep-state is stored away, and when a "check state" is run, > it effectively JUMPS TO the rule that did the keep-state. > Ah! thanks for that! As it happens that's just what I need. In many cases in my rule set I use add pipe ................ keep-state and that works as I had hoped it would -- this explains why. Thanks also to the other folk on the list (Hi Vadim) who have helped me get this show on the road. Yesterday I shut down the interfaces on the primary firewall to force the traffic to the secondary where I had my rewritten rule set up and no one noticed (except those who had tcp sessions in progress at the time). Are there any plans for state synchronisation (like pfsync) for ipfw or is there something and I have missed it? Russell. From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 5 22:43:15 2007 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB3116A417 for ; Wed, 5 Sep 2007 22:43:15 +0000 (UTC) (envelope-from yamamoto436@oki.com) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by mx1.freebsd.org (Postfix) with ESMTP id B8C8913C45E for ; Wed, 5 Sep 2007 22:43:15 +0000 (UTC) (envelope-from yamamoto436@oki.com) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id 5C808CF9C0; Thu, 6 Sep 2007 07:20:56 +0900 (JST) Received: from s24c22.dm1.oii.oki.co.jp [172.26.76.72] by gwf1.oki.co.jp with ESMTP id HAA12385; Thu, 6 Sep 2007 07:20:56 +0900 Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id HAA00775 for ; Thu, 6 Sep 2007 07:20:54 +0900 Received: (qmail 23732 invoked from network); 6 Sep 2007 07:20:54 +0900 Received: from tulip.bmc.oki.co.jp (172.19.236.119) by aoi.bmc.oki.co.jp with SMTP; 6 Sep 2007 07:20:54 +0900 Received: from localhost (tulip.bmc.oki.co.jp [172.19.236.119]) by tulip.bmc.oki.co.jp (8.14.1/8.13.6) with ESMTP id l85MKs8s057485; Thu, 6 Sep 2007 07:20:54 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Thu, 06 Sep 2007 07:20:54 +0900 (JST) Message-Id: <20070906.072054.104084815.yamamoto436@oki.com> To: skafte+freebsd-ipfw@trollkarl.net From: Hideki Yamamoto In-Reply-To: <20070827174721.GA62693@trollkarl.trollkarl.net> References: <20070827174721.GA62693@trollkarl.trollkarl.net> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org Subject: Re: dscp support 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: Wed, 05 Sep 2007 22:43:16 -0000 Hi, I also agree with Greg's opinion. I had found a small bug in this patch and have planned to extend it to IPv6 packet. I am now testing my new patch. Please take care of using it. From: Greg Skafte Subject: dscp support Date: Mon, 27 Aug 2007 11:47:22 -0600 Message-ID: <20070827174721.GA62693@trollkarl.trollkarl.net> > did anyone every take a more indepth look at kern/102471 (tos and scp support). > It would be useful for doing more advanced work with VOIP and more advanced > queueing with equipment that manipulates dscp fields (avaya pbx's and cisco > sip products) > > > > -- > Email: skafte@trollkarl.net Contact me for ICQ,MSN,AIM,Yahoo,Jabber > -- -- > When things can't get any worse, they simplify themselves by getting a > whole lot worse then complicated. A complete and utter disaster is the > simplest thing in the world; it's preventing one that's complex. > (Janet Morris) Hideki Yamamoto ----------------------------------------------------------------- Hideki YAMAMOTO (Dr.) | Broadband Media Solutions Department-1 | E-mail: yamamoto436@oki.com Broadband Media Company | Tel: +81-48-420-7012 Oki Electric Industry Co., Ltd. | FAX: +81-48-420-7016 From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 6 02:26:40 2007 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 15CD516A418 for ; Thu, 6 Sep 2007 02:26:40 +0000 (UTC) (envelope-from kansas_le@yahoo.com) Received: from web56801.mail.re3.yahoo.com (web56801.mail.re3.yahoo.com [66.196.97.75]) by mx1.freebsd.org (Postfix) with SMTP id C38F013C45D for ; Thu, 6 Sep 2007 02:26:39 +0000 (UTC) (envelope-from kansas_le@yahoo.com) Received: (qmail 24722 invoked by uid 60001); 6 Sep 2007 01:59:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1WLvtxU8D7Y0duEBOKNqtqpWsGoBze2BTEdQE4e2IV5k5kIP5lsvQGSnlHXxvK0Pifg7F3r/7dj603Nx0phRTokvtYZnMEvLPgNLXpEpUHuDC4Xett03bCcHMLJB/I3wiwAbk+EvTKwPbpIvzd1yyHFtsDTHHBkZ/Mz2vcGDgZs=; X-YMail-OSG: mmFhRAYVM1mHxSyObWcFEkuUnOPvQTzLgR.xTdTEMjN.FmAXrnxdThvkHJtFbmZ6q9MgkOMILSqqpkxWT7ys3YFb0sni_BwiUH.zexRSauWGfKEonAjnb.w.8ctMCA-- Received: from [125.160.216.194] by web56801.mail.re3.yahoo.com via HTTP; Wed, 05 Sep 2007 18:59:45 PDT Date: Wed, 5 Sep 2007 18:59:45 -0700 (PDT) From: Stephen GL To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Message-ID: <456319.24028.qm@web56801.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Allow only match both mac address and IP address 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, 06 Sep 2007 02:26:40 -0000 Hi, I need help. I am very new about IPFW. I'm in FreeBSD 6.0. My job is pass anyone that has a valid both MAC and IP address. Beginning of my rule I check the valid MAC address that can get through. If pass, the next rule is check the IP address. If pass, he/she can get through. Everything is work as expected. My problem is the above rules doesn't check both MAC and IP address pairing. Assume someone spoof other MAC address, they can pass by changing the IP address of another. Another question, if really someone has both valid MAC and IP address, but in fact he/she was a spoofer or man in the middle in the same subnet. How to accomplish this problem, I heard about static ARP table, but not interested to setup that kind of solution. I am thinking about nmap. Which can check against my database about valid Ethernet ID and Operating System being used. Anyone has done this kind of solution? -- Stephen --------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 6 03:09:27 2007 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 817FC16A418 for ; Thu, 6 Sep 2007 03:09:27 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: from smtpout07.prod.mesa1.secureserver.net (smtpout07-04.prod.mesa1.secureserver.net [64.202.165.233]) by mx1.freebsd.org (Postfix) with SMTP id 4FB7C13C45E for ; Thu, 6 Sep 2007 03:09:27 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: (qmail 32431 invoked from network); 6 Sep 2007 02:42:23 -0000 Received: from unknown (70.113.73.215) by smtpout07-04.prod.mesa1.secureserver.net (64.202.165.233) with ESMTP; 06 Sep 2007 02:42:23 -0000 Message-ID: <46DF68EE.1010905@austin.rr.com> Date: Wed, 05 Sep 2007 21:41:50 -0500 From: "Chris Bowman (Home)" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, Chris Bowman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [6.x patchset] Ipfw nat and libalias modules 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, 06 Sep 2007 03:09:27 -0000 I was recently testing the in kernel nat patch, which is an absolutely wonderful addition in my opinion. I have however run into one issue, when for example I do the following : ipfw nat 10 config ip 2.2.2.2 The command is accepted, and anything I sent to nat process 10 via ipfw works as expected. When I try to add a second NAT instance though, I run into a problem, for example : ipfw nat 20 config ip 3.3.3.3 My goal is to of course have more than one nat process running, but adding anything after that initial first NAT causes a "hang", when I say hang I mean I enter the command, hit enter, and am never returned to a prompt, if I break with CTRL-C, then I can get back to the prompt most of the time, other times I cannot break out via CTRL-C and just have to close that particular shell session. To note, when I run into this hang, the command I ran shows up as a process, ie like this : 3839 p3 R+ 0:02.67 ipfw nat 30 config ip 4.4.4.4 At this point, if I can't break out via CTRL-C , in another shell on the same machine I tried to kill the process, then kill -9, neither works, the process stays until I reboot the machine. Finally, just to note, even if the command doesn't return me to a shell prompt, or even if it hangs, the nat processes themselves to work, if I do a "ipfw nat show config" , all is well, and I've tested to be sure, the nat processes are definitely active and working as they should. To reproduce the problem Im seeing, simply try : ipfw nat 10 config ip 1.1.1.1 <== Works Fine ipfw nat 20 config ip 2.2.2.2 <== Won't return you back to a shell Prompt I've tried this on x86 as well as AMD64, both having the same exact problem. Both machines are running 6.1-RELEASE-p19 Please let me know if I can help with additional information, and by the way, aside from this small issue, in kernel nat is absoulutely awesome, thanks for all the hard work! Chris Bowman From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 6 05:15:03 2007 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 AD69D16A417 for ; Thu, 6 Sep 2007 05:15:03 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by mx1.freebsd.org (Postfix) with SMTP id 789DF13C458 for ; Thu, 6 Sep 2007 05:15:03 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: (qmail 5883 invoked from network); 6 Sep 2007 04:14:47 -0000 Received: from unknown (70.113.73.215) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 06 Sep 2007 04:14:47 -0000 Message-ID: <46DF7E94.8030208@austin.rr.com> Date: Wed, 05 Sep 2007 23:14:12 -0500 From: "Chris Bowman (Home)" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen GL References: <456319.24028.qm@web56801.mail.re3.yahoo.com> In-Reply-To: <456319.24028.qm@web56801.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: Allow only match both mac address and IP address 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, 06 Sep 2007 05:15:03 -0000 Stephen GL wrote: > Hi, > > I need help. > I am very new about IPFW. I'm in FreeBSD 6.0. > My job is pass anyone that has a valid both MAC and IP address. > Beginning of my rule I check the valid MAC address that can get through. > If pass, the next rule is check the IP address. > If pass, he/she can get through. > > Everything is work as expected. My problem is the above rules doesn't check both MAC and IP address pairing. Assume someone spoof other MAC address, they can pass by changing the IP address of another. > > Another question, if really someone has both valid MAC and IP address, but in fact he/she was a spoofer or man in the middle in the same subnet. How to accomplish this problem, I heard about static ARP table, but not interested to setup that kind of solution. I am thinking about nmap. Which can check against my database about valid Ethernet ID and Operating System being used. Anyone has done this kind of solution? > > -- > Stephen > > > --------------------------------- > Building a website is a piece of cake. > Yahoo! Small Business gives you all the tools to get online. > _______________________________________________ > 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" > > Make sure *net.link.ether.ipfw* is enabled, assuming it is since you said you had it partially working. Then use the following rules as a guidline : -- Outbound Rule -- allow ip from 172.16.100.50 to any MAC any 00:11:22:33:44:55 --Inbound Rule-- allow ip from any to 172.16.100.50 MAC 00:11:22:33:44:55 any Of course it seems your main concern is allowing people out that are indeed authorized, so you could likely make the inbound rule alot more general, something along the lines of : allow ip from any to 172.16.100.0/24 MAC any any Hope that helps! Chris Bowman From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 6 13:07:24 2007 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 2F9F316A41B for ; Thu, 6 Sep 2007 13:07:24 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id E147B13C48D for ; Thu, 6 Sep 2007 13:07:23 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-84-221-89-199.cust-adsl.tiscali.it [84.221.89.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 30A4F11AE7A; Thu, 6 Sep 2007 14:34:06 +0200 (CEST) Received: (from piso@localhost) by southcross.wired.org (8.14.1/8.14.1/Submit) id l86CYIFh095099; Thu, 6 Sep 2007 14:34:18 +0200 (CEST) (envelope-from piso) Date: Thu, 6 Sep 2007 14:34:17 +0200 From: Paolo Pisati To: "Chris Bowman (Home)" Message-ID: <20070906123417.GA95067@tin.it> References: <46DF68EE.1010905@austin.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DF68EE.1010905@austin.rr.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-ipfw@freebsd.org, Chris Bowman Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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, 06 Sep 2007 13:07:24 -0000 On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote: > > I was recently testing the in kernel nat patch, which is an absolutely > wonderful addition in my opinion. I have however run into one issue, when > for example I do the following : > > ipfw nat 10 config ip 2.2.2.2 [snip] Where did you get the 6.x patch? Did you find a tarball around or you backported the code from 7.x? In the first case, that patch is old and buggy, and AFAIK the bug you encountered was due to an uninitialized conditional variable. bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 6 15:20:48 2007 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 EC76716A41B for ; Thu, 6 Sep 2007 15:20:48 +0000 (UTC) (envelope-from chris@korcett.com) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-04.prod.mesa1.secureserver.net [64.202.165.238]) by mx1.freebsd.org (Postfix) with SMTP id 9AE5013C478 for ; Thu, 6 Sep 2007 15:20:48 +0000 (UTC) (envelope-from chris@korcett.com) Received: (qmail 23901 invoked from network); 6 Sep 2007 14:54:07 -0000 Received: from unknown (71.42.72.220) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 06 Sep 2007 14:54:06 -0000 Message-ID: <46E0146D.8060508@korcett.com> Date: Thu, 06 Sep 2007 09:53:33 -0500 From: Chris Bowman Organization: KHI User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paolo Pisati References: <46DF68EE.1010905@austin.rr.com> <20070906123417.GA95067@tin.it> In-Reply-To: <20070906123417.GA95067@tin.it> Content-Type: multipart/mixed; boundary="------------050804050202030505010607" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org, "Chris Bowman \(Home\)" Subject: Re: [6.x patchset] Ipfw nat and libalias modules X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chris@korcett.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2007 15:20:49 -0000 This is a multi-part message in MIME format. --------------050804050202030505010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It was indeed the tarball downloaded from http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz ... Thank you, I'll give the 7.x code a try. Paolo Pisati wrote: > On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote: > >> I was recently testing the in kernel nat patch, which is an absolutely >> wonderful addition in my opinion. I have however run into one issue, when >> for example I do the following : >> >> ipfw nat 10 config ip 2.2.2.2 >> > [snip] > > Where did you get the 6.x patch? Did you find a tarball around or > you backported the code from 7.x? > > In the first case, that patch is old and buggy, and AFAIK the bug you encountered > was due to an uninitialized conditional variable. > > bye, > P. > > > -- --------------050804050202030505010607-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Sep 7 17:25:11 2007 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 F32F016A419 for ; Fri, 7 Sep 2007 17:25:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id CCBCE13C46A for ; Fri, 7 Sep 2007 17:25:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id EE4A85C78; Fri, 7 Sep 2007 12:53:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26pgT6tIWmQR; Fri, 7 Sep 2007 12:53:10 -0400 (EDT) Received: from [192.168.1.3] (pool-71-190-65-187.nycmny.east.verizon.net [71.190.65.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 1F3D15C19; Fri, 7 Sep 2007 12:53:10 -0400 (EDT) Message-ID: <46E181F1.2030404@mac.com> Date: Fri, 07 Sep 2007 12:53:05 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Stephen GL References: <456319.24028.qm@web56801.mail.re3.yahoo.com> In-Reply-To: <456319.24028.qm@web56801.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: Allow only match both mac address and IP address 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, 07 Sep 2007 17:25:11 -0000 Stephen GL wrote: [ ... ] > I am very new about IPFW. I'm in FreeBSD 6.0. > My job is pass anyone that has a valid both MAC and IP address. > Beginning of my rule I check the valid MAC address that can get through. > If pass, the next rule is check the IP address. > If pass, he/she can get through. > > Everything is work as expected. My problem is the above rules doesn't check > both MAC and IP address pairing. Assume someone spoof other MAC address, they > can pass by changing the IP address of another. The way to deal with people who screw up your network by spoofing the MAC and IP address of another machine is to fire them or drop them as a customer, depending on the relationship. However, if you really need to provide IP access to people whom you can't trust not to play such games, consider switching to something which requires authentication, such as PPPoE. -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Fri Sep 7 19:00:50 2007 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 4100216A420 for ; Fri, 7 Sep 2007 19:00:49 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id C4E5813C45A for ; Fri, 7 Sep 2007 19:00:47 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l87Ht0P9097691; Fri, 7 Sep 2007 14:55:01 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Fri, 7 Sep 2007 14:54:06 -0300 User-Agent: KMail/1.9.7 References: <456319.24028.qm@web56801.mail.re3.yahoo.com> <46E181F1.2030404@mac.com> In-Reply-To: <46E181F1.2030404@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071454.07445.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: Stephen GL Subject: Re: Allow only match both mac address and IP address 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, 07 Sep 2007 19:00:50 -0000 On Friday 07 September 2007 13:53:05 Chuck Swiger wrote: > Stephen GL wrote: > [ ... ] > > > I am very new about IPFW. I'm in FreeBSD 6.0. > > My job is pass anyone that has a valid both MAC and IP address. > > Beginning of my rule I check the valid MAC address that can get through. > > If pass, the next rule is check the IP address. > > If pass, he/she can get through. > > > > Everything is work as expected. My problem is the above rules doesn't > > check both MAC and IP address pairing. Assume someone spoof other MAC > > address, they can pass by changing the IP address of another. > > The way to deal with people who screw up your network by spoofing the MAC > and IP address of another machine is to fire them or drop them as a > customer, depending on the relationship. > a completely brilliant solution, technically brilliant, administrationally brilliant, please accept my admiration ... but we want the customer's money and not drop them man ... > However, if you really need to provide IP access to people whom you can't > trust not to play such games, consider switching to something which > requires authentication, such as PPPoE. that then cost money for password capslock/lost/forgot/change support ... and cost bandwidth overhead or the costumer get less bandwidth as supposed to back to the point, you need to run your server as bridge then you can drop traffic which is not an authorized mac/ip pair as in deny ip from any to any src-ip ${ip} layer2 not MAC any ${mac} recv ${nic} JM A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Sat Sep 8 04:40:31 2007 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 143CB16A418 for ; Sat, 8 Sep 2007 04:40:31 +0000 (UTC) (envelope-from kansas_le@yahoo.com) Received: from web56809.mail.re3.yahoo.com (web56809.mail.re3.yahoo.com [66.196.97.83]) by mx1.freebsd.org (Postfix) with SMTP id C856213C461 for ; Sat, 8 Sep 2007 04:40:30 +0000 (UTC) (envelope-from kansas_le@yahoo.com) Received: (qmail 90619 invoked by uid 60001); 8 Sep 2007 04:40:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=A7abjl5mPbLBek8DoF5e+SHpP8ej9jtGeZZpcGea8ERv5BINUeewzs/iO14r39k2I6PP5OX4MJ0RWQg1POnrFnjzGUqQTYwv/bRRWtETaZAcrCRASHv6tptWUgGBp7zvH6NvbddmlZ3ByyyApfDx67QT3X5UhrPD3k1WUwchM6M=; X-YMail-OSG: lvniV9IVM1mVNZT3ylKuGvfVKcegfZJGW6pwwGjMrvRiDXzhPiWnXsOHnDdNShgHRN8.grY1pZt2pGFOul1cBucUACcbrJuUAUCG6spRHghgdQs4_5jNyfhE3x9C7A-- Received: from [125.160.216.194] by web56809.mail.re3.yahoo.com via HTTP; Fri, 07 Sep 2007 21:40:29 PDT Date: Fri, 7 Sep 2007 21:40:29 -0700 (PDT) From: Stephen GL To: AT Matik , freebsd-ipfw@freebsd.org In-Reply-To: <200709071454.07445.asstec@matik.com.br> MIME-Version: 1.0 Message-ID: <984691.90507.qm@web56809.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Stephen GL Subject: Re: Allow only match both mac address and IP address 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: Sat, 08 Sep 2007 04:40:31 -0000 Thanks to Chris and JM, I did check the pair of IP and MAC right now. My office has a small group of spoofer, so far they are IP address spoofer, which is already blocked as they has invalid MAC Address. It's funny if you see them right now, keep thinking why I can't get through. I realize that one day, soon they will become an expert of IP and MAC Address spoofer. For Windows users, SMAC is too easy to find. I don't want they laugh at me, as they laughed at me when I only block the IP address alone. Is there another (additional) way that IPFW can check against fake interface? Don't tell me about OS fingerprint, I know that it's in fact changeable by known valid user. And also the CGI login, some valid user I know in fact is friend of spoofer. Stephen AT Matik wrote: On Friday 07 September 2007 13:53:05 Chuck Swiger wrote: > Stephen GL wrote: > [ ... ] > > > I am very new about IPFW. I'm in FreeBSD 6.0. > > My job is pass anyone that has a valid both MAC and IP address. > > Beginning of my rule I check the valid MAC address that can get through. > > If pass, the next rule is check the IP address. > > If pass, he/she can get through. > > > > Everything is work as expected. My problem is the above rules doesn't > > check both MAC and IP address pairing. Assume someone spoof other MAC > > address, they can pass by changing the IP address of another. > > The way to deal with people who screw up your network by spoofing the MAC > and IP address of another machine is to fire them or drop them as a > customer, depending on the relationship. > a completely brilliant solution, technically brilliant, administrationally brilliant, please accept my admiration ... but we want the customer's money and not drop them man ... > However, if you really need to provide IP access to people whom you can't > trust not to play such games, consider switching to something which > requires authentication, such as PPPoE. that then cost money for password capslock/lost/forgot/change support ... and cost bandwidth overhead or the costumer get less bandwidth as supposed to back to the point, you need to run your server as bridge then you can drop traffic which is not an authorized mac/ip pair as in deny ip from any to any src-ip ${ip} layer2 not MAC any ${mac} recv ${nic} JM A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br _______________________________________________ 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" --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. From owner-freebsd-ipfw@FreeBSD.ORG Sat Sep 8 13:23:13 2007 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 374A616A468 for ; Sat, 8 Sep 2007 13:23:13 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-04.prod.mesa1.secureserver.net [64.202.165.238]) by mx1.freebsd.org (Postfix) with SMTP id DEFE113C45D for ; Sat, 8 Sep 2007 13:23:12 +0000 (UTC) (envelope-from chrishome@austin.rr.com) Received: (qmail 26071 invoked from network); 8 Sep 2007 13:23:11 -0000 Received: from unknown (70.113.75.58) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 08 Sep 2007 13:23:11 -0000 Message-ID: <46E2A20B.8010306@austin.rr.com> Date: Sat, 08 Sep 2007 08:22:19 -0500 From: "Chris Bowman (Home)" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: chris@korcett.com References: <46DF68EE.1010905@austin.rr.com> <20070906123417.GA95067@tin.it> <46E0146D.8060508@korcett.com> In-Reply-To: <46E0146D.8060508@korcett.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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: Sat, 08 Sep 2007 13:23:13 -0000 > >> On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote: >> >>> I was recently testing the in kernel nat patch, which is an >>> absolutely wonderful addition in my opinion. I have however run >>> into one issue, when for example I do the following : >>> >>> ipfw nat 10 config ip 2.2.2.2 >>> >> [snip] >> >> Where did you get the 6.x patch? Did you find a tarball around or you >> backported the code from 7.x? >> >> In the first case, that patch is old and buggy, and AFAIK the bug you >> encountered was due to an uninitialized conditional variable. >> >> bye, >> P. >> >> >> I'm having a bit of trouble backporting 7.x to 6.x, 6.2 Release specifically. Before I continue down this road, in the name of not re-inventing the wheel twice, does anyone already have a current patch which will work on 6.2 ? Thank You! Chris Bowman