From owner-freebsd-ipfw@FreeBSD.ORG Sun Jan 16 04:21:27 2011 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 B83C6106566B; Sun, 16 Jan 2011 04:21:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 2004A8FC12; Sun, 16 Jan 2011 04:21:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p0G4LUqA062027; Sun, 16 Jan 2011 15:21:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 16 Jan 2011 15:21:30 +1100 (EST) From: Ian Smith To: Hiroki Sato In-Reply-To: <20110116.011206.258445491489571055.hrs@allbsd.org> Message-ID: <20110116132702.A62193@sola.nimnet.asn.au> References: <20110108141111.A15397@sola.nimnet.asn.au> <20110108220300.Q15397@sola.nimnet.asn.au> <20110116.011206.258445491489571055.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: jamesbrandongooch@gmail.com, freebsd-ipfw@freebsd.org, emax@freebsd.org Subject: Re: Request for policy decision: kernel nat vs/and/or natd 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, 16 Jan 2011 04:21:27 -0000 On Sun, 16 Jan 2011, Hiroki Sato wrote: > Ian Smith wrote > in <20110108220300.Q15397@sola.nimnet.asn.au>: > > sm> On Sat, 8 Jan 2011 15:02:29 +1100, Ian Smith wrote: > sm> > On Fri, 7 Jan 2011, Brandon Gooch wrote: > sm> > > On Thu, Dec 23, 2010 at 8:58 AM, Ian Smith wrote: > sm> [..] > sm> > > > We could: > sm> > > > > sm> > > > 1) Preference kernel nat over natd when both are enabled. > sm> > > > sm> > > I vote for #1. > sm> > > sm> > Thanks. So far, that makes an overwhelming majority of 2 / NIL :) > sm> > > sm> > I see that hrs@freebsd.org has just grabbed two related PRs: > sm> > > sm> > kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup > sm> > conf/153155: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled > sm> > > sm> > so this seems a good time to work up patches to that effect for review > sm> > (/etc/rc.d/ipfw, maybe natd, /etc/rc.firewall) later tonight my time. > sm> > sm> Ok, the attached patches are against HEAD, which is currently identical > sm> to 8-STABLE for these files. rc.d_ipfw.patch also applies to 7-STABLE > sm> with an offset but rc.firewall.patch needs more work for 7. I've no box > sm> on which to actually run-test tonight, and will be away for a few days. > sm> > sm> /etc/rc.d/ipfw: > sm> . prefer kernel nat (loading ipfw_nat) to natd when both are enabled > sm> . add ipdivert to required_modules - when only natd is enabled - as > sm> proposed by Thomas Sandford in conf/153155 and also re kern/148928 > sm> also fixing the related issue in conf/148137 (and possibly others) > sm> . prefix /etc/rc.d/natd to firewall_coscripts when only natd is enabled > sm> > sm> /etc/rc.d/natd: > sm> . seems nothing is needed; has KEYWORD nostart and so should only be > sm> started now by ipfw when natd - but not firewall_nat - is enabled > sm> > sm> /etc/rc.firewall: > sm> . move firewall_nat and natd code into a function, setup_nat() > sm> preferring kernel firewall_nat to natd if both are enabled > sm> . couldn't resist tidying up that code to within 80 columns > sm> . call setup_nat also in 'simple' ruleset, with same intent as > sm> proposed in conf/148144 by David Naylor > sm> . couldn't resist fixing unnecessarily long line in 'workstation' > > The patches look good to me, but one thing I am wondering is > rc.d/natd invocation in rc.d/ipfw. When natd_enable="YES", rc.d/natd > invokes the daemon after the rc.d/ipfw script eventually even if > firewall_nat_enable="YES". What do you think about adding natd to > REQUIRE: line of rc.d/ipfw? Although I did not test it extensively, > rc.d/natd can run safely before rc.d/ipfw and using REQUIRE is > reasonable instead of using $firewall_coscripts from a viewpoint of > the rc.d framework. Hello Hiroki, I'm not sure why, with the use of firewall_coscripts, natd was made to start AFTER ipfw rules are loaded but BEFORE enabling the firewall, so I don't know whether there had been negative consequences of starting natd first? Nor do I know of any other use of firewall_coscripts, so adding emax@ to the (trimmed) cc list as the committer of that change. http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ipfw.diff?r1=1.22;r2=1.23;f=h shows that prior to that change, rc.d/natd was run - so the daemon was started - before the firewall rules were loaded, which would remove the present need to add ipdivert to required_modules (conditionally) in ipfw_prestart. ipfw_stop() still needs to kill natd if running though, noticing also the comment with rc.d/natd rev 1.1 over 6 years ago: === Add separate script for natd. This fixes race condition with "ipfw restart" (when new natd is started before old natd died) and allows to manage natd without touching ipfw. natd should probably be killed with SIGKILL when stopping natd. === Because rc.d/natd has KEYWORD nostart, I gathered that it won't run on startup, and by NOT prefixing it to _coscripts when firewall_nat is also enabled, as in this patch, it won't be invoked by ipfw either. However it could still be run manually, so really should have an explicit test to NOT start /sbin/natd whenever firewall_nat="YES", assuming policy #1. And if rc.d/natd has such an explicit test for ! firewall_nat_enabled, then it wouldn't matter when or how rc.d/natd was invoked? I'm not sure how one should cleanly abandon an rc.d script without starting/stopping anything though?, or I'd offer such a patch now. If rc.d/natd can really _always_ be invoked safely before starting ipfw, then the REQUIRE method should be fine - as long as rc.d/natd quits if $firewall_nat is enabled - but I'm not sure how that may work especially if the interface concerned relies on DHCP (ie -dynamic) and/or if the interface hasn't an address yet, as CAN happen with ppp or (here) mpd? Any more thoughts on start/stop ordering or interdependent conditions? cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 17 04:59:34 2011 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 966871065670; Mon, 17 Jan 2011 04:59:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id A77508FC17; Mon, 17 Jan 2011 04:59:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p0H4xgP3040358; Mon, 17 Jan 2011 15:59:43 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 17 Jan 2011 15:59:42 +1100 (EST) From: Ian Smith To: Hiroki Sato In-Reply-To: <20110116132702.A62193@sola.nimnet.asn.au> Message-ID: <20110117151457.P81591@sola.nimnet.asn.au> References: <20110108141111.A15397@sola.nimnet.asn.au> <20110108220300.Q15397@sola.nimnet.asn.au> <20110116.011206.258445491489571055.hrs@allbsd.org> <20110116132702.A62193@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1464532019-1295240382=:81591" Cc: jamesbrandongooch@gmail.com, freebsd-ipfw@freebsd.org, emax@freebsd.org Subject: Re: Request for policy decision: kernel nat vs/and/or natd 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, 17 Jan 2011 04:59:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1464532019-1295240382=:81591 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 16 Jan 2011, Ian Smith wrote: > On Sun, 16 Jan 2011, Hiroki Sato wrote: > > Ian Smith wrote > > in <20110108220300.Q15397@sola.nimnet.asn.au>: > > > > sm> On Sat, 8 Jan 2011 15:02:29 +1100, Ian Smith wrote: > > sm> > On Fri, 7 Jan 2011, Brandon Gooch wrote: > > sm> > > On Thu, Dec 23, 2010 at 8:58 AM, Ian Smith wrote: [..] > > sm> /etc/rc.d/ipfw: > > sm> . prefer kernel nat (loading ipfw_nat) to natd when both are enabled > > sm> . add ipdivert to required_modules - when only natd is enabled - as > > sm> proposed by Thomas Sandford in conf/153155 and also re kern/148928 > > sm> also fixing the related issue in conf/148137 (and possibly others) > > sm> . prefix /etc/rc.d/natd to firewall_coscripts when only natd is enabled > > sm> > > sm> /etc/rc.d/natd: > > sm> . seems nothing is needed; has KEYWORD nostart and so should only be > > sm> started now by ipfw when natd - but not firewall_nat - is enabled Addressed below. > > sm> /etc/rc.firewall: > > sm> . move firewall_nat and natd code into a function, setup_nat() > > sm> preferring kernel firewall_nat to natd if both are enabled > > sm> . couldn't resist tidying up that code to within 80 columns > > sm> . call setup_nat also in 'simple' ruleset, with same intent as > > sm> proposed in conf/148144 by David Naylor > > sm> . couldn't resist fixing unnecessarily long line in 'workstation' > > > > The patches look good to me, but one thing I am wondering is > > rc.d/natd invocation in rc.d/ipfw. When natd_enable="YES", rc.d/natd > > invokes the daemon after the rc.d/ipfw script eventually even if > > firewall_nat_enable="YES". What do you think about adding natd to > > REQUIRE: line of rc.d/ipfw? Although I did not test it extensively, > > rc.d/natd can run safely before rc.d/ipfw and using REQUIRE is > > reasonable instead of using $firewall_coscripts from a viewpoint of > > the rc.d framework. > > Hello Hiroki, Sorry to follow-up my own post, but after more research: > I'm not sure why, with the use of firewall_coscripts, natd was made to > start AFTER ipfw rules are loaded but BEFORE enabling the firewall, so I > don't know whether there had been negative consequences of starting natd > first? Nor do I know of any other use of firewall_coscripts, so adding > emax@ to the (trimmed) cc list as the committer of that change. Given someone/s may be using firewall_coscripts, without confirmation to the contrary I'd be inclined to leave that mechanism alone, except the avoidance of prefixing natd to _coscripts when firewall_nat is enabled. [..] > Because rc.d/natd has KEYWORD nostart, I gathered that it won't run on > startup, and by NOT prefixing it to _coscripts when firewall_nat is also > enabled, as in this patch, it won't be invoked by ipfw either. However > it could still be run manually, so really should have an explicit test > to NOT start /sbin/natd whenever firewall_nat="YES", assuming policy #1. > > And if rc.d/natd has such an explicit test for ! firewall_nat_enabled, > then it wouldn't matter when or how rc.d/natd was invoked? I'm not sure > how one should cleanly abandon an rc.d script without starting/stopping > anything though?, or I'd offer such a patch now. Ok, after studying rc.subr(8) and examining lots of rc.d scripts, the attached rc.d_natd.patch should deal with that gracefully, also warning the user that natd will not be started because firewall_nat is enabled. > If rc.d/natd can really _always_ be invoked safely before starting ipfw, > then the REQUIRE method should be fine - as long as rc.d/natd quits if > $firewall_nat is enabled - but I'm not sure how that may work especially > if the interface concerned relies on DHCP (ie -dynamic) and/or if the > interface hasn't an address yet, as CAN happen with ppp or (here) mpd? I still feel a bit uneasy about also altering the start/stop ordering when the main reason anyone wanted to start natd first was to ensure that ipdivert was loaded before encountering divert rules, now dealt with by ipfw_prestart. > Any more thoughts on start/stop ordering or interdependent conditions? cheers, Ian --0-1464532019-1295240382=:81591 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=rc.d_natd.patch Content-Transfer-Encoding: BASE64 Content-ID: <20110117155942.V81591@sola.nimnet.asn.au> Content-Description: Content-Disposition: attachment; filename=rc.d_natd.patch LS0tIG5hdGQuMS41LjEwLjEJVGh1IERlYyAyMyAxNjoyMDowOCAyMDEwDQor KysgbmF0ZAlNb24gSmFuIDE3IDE0OjUwOjEwIDIwMTENCkBAIC0xOCw2ICsx OCwxMSBAQA0KIA0KIG5hdGRfcHJlY21kKCkNCiB7DQorCWlmIGNoZWNreWVz bm8gZmlyZXdhbGxfbmF0X2VuYWJsZTsgdGhlbg0KKwkJd2FybiAibm90IHN0 YXJ0ZWQ6IGZpcmV3YWxsX25hdCBpcyBlbmFibGVkIg0KKwkJcmV0dXJuIDEN CisJZmkNCisNCiAJaWYgWyAtbiAiJHtuYXRkX2ludGVyZmFjZX0iIF07IHRo ZW4NCiAJCWRoY3BfbGlzdD0iYGxpc3RfbmV0X2ludGVyZmFjZXMgZGhjcGAi DQogCQlmb3IgaWZuIGluICR7ZGhjcF9saXN0fTsgZG8NCg== --0-1464532019-1295240382=:81591-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 17 11:07:01 2011 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 BD0B6106564A for ; Mon, 17 Jan 2011 11:07:01 +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 AB1758FC12 for ; Mon, 17 Jan 2011 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0HB71RY048915 for ; Mon, 17 Jan 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0HB71Vr048912 for freebsd-ipfw@FreeBSD.org; Mon, 17 Jan 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Jan 2011 11:07:01 GMT Message-Id: <201101171107.p0HB71Vr048912@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, 17 Jan 2011 11:07:01 -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/153415 ipfw [ipfw] [patch] Port numbers always zero in dynamic IPF o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152887 ipfw [ipfw] Can not set more then 1024 buckets with buckets o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/150798 ipfw [ipfw] ipfw2 fwd rule matches packets but does not do o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should 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/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 o kern/122109 ipfw [ipfw] ipfw nat traceroute problem 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 (corr 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 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 docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets 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/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 bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou 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 78 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 17 18:29:12 2011 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 99005106566B for ; Mon, 17 Jan 2011 18:29:12 +0000 (UTC) (envelope-from fam@sky.net.pk) Received: from smtp-gw4.ptcl.net (smtp-gw4.ptcl.net [203.99.163.175]) by mx1.freebsd.org (Postfix) with ESMTP id DD39A8FC12 for ; Mon, 17 Jan 2011 18:29:09 +0000 (UTC) X-ASG-Debug-ID: 1295288268-6e728d7e0002-eNwBcy Received: from fam ([119.156.53.156]) by smtp-gw4.ptcl.net with SMTP id ySD3HxoEMNyX92XG for ; Mon, 17 Jan 2011 23:18:01 +0500 (PKT) X-Barracuda-Envelope-From: fam@sky.net.pk Message-ID: <0C410D9FC67644B397092B0709802DC9@fam> From: "Fazal Ahmed Malik" To: Date: Mon, 17 Jan 2011 23:17:52 +0500 X-ASG-Orig-Subj: transparent squid and ipfw MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01CBB69C.C37A80D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Barracuda-Connect: UNKNOWN[119.156.53.156] X-Barracuda-Start-Time: 1295288268 X-Barracuda-URL: http://203.99.163.175:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ptcl.net X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=5.0 KILL_LEVEL=5.5 tests=BSF_SC0_TG035a, HTML_MESSAGE, MIME_QP_LONG_LINE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.52655 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.82 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.00 BSF_SC0_TG035a Message contains invalid style definition X-Mailman-Approved-At: Mon, 17 Jan 2011 20:14:36 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: transparent squid and ipfw 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, 17 Jan 2011 18:29:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CBB69C.C37A80D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, =20 I have problem in setting up transparent squid and ipfw dummynet = together on freebsd. I sent this question earlier but yet no luck to = implement. I am using mpd5 for pppoe server and have addclient script = which limit the user bandwidth(working perfect) now i want my all = traffic redirected to squid transparently mean users does not need to = configure their browser for proxy. When i redirect port 80 traffic to = squid than bandwidth does not get controlled mean dummy net pipe is no = more effective. I have following ipfw rules and also addclient script is attached any = body having implemented such solution please help. 00002 157925 116380443 divert 8668 ip from any to any via xl0 00997 fwd 192.168.3.50,8080 $log tcp from any to any 80 in recv $vpn_if 00048 6 288 deny tcp from any to any dst-port 445 out via xl0 00049 0 0 deny tcp from any to any dst-port 445 in via xl0 00050 0 0 deny tcp from any to any dst-port 137 in via xl0 00051 0 0 deny tcp from any to any dst-port 138 in via xl0 00052 0 0 deny tcp from any to any dst-port 139 in via xl0 00053 0 0 allow tcp from any to any dst-port 20 setup 00054 0 0 allow tcp from any to any dst-port 21 setup 00055 0 0 allow tcp from any to any dst-port 22 setup 00056 5 240 allow tcp from any to any dst-port 23 setup 00999 287274 228262006 allow tcp from any to any out keep-state 01003 1298 140582 pipe 3 ip from 192.168.3.80 to any via ng0 01005 3654 409511 pipe 5 ip from 192.168.3.81 to any via ng1 03000 772 52308 allow icmp from me to any 04000 394 26536 allow icmp from any to any 65535 33414 5509180 allow ip from any to any Best regards, Fazal Ahmed Malik ------=_NextPart_000_0007_01CBB69C.C37A80D0 Content-Type: application/octet-stream; name="addclient.sh" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="addclient.sh" #!/bin/sh=0A= user=3D$5 #grab args off the command line (USER, type, HISADDR, = INTERFACE)=0A= type=3D$2=0A= clientip=3D$4=0A= int=3D$1=0A= fwcmd=3D/sbin/ipfw #specify firewall command=0A= =0A= usernum1=3D${int#ng}=0A= usernum=3D`expr $usernum1 + 1`=0A= inkbps=3D`grep -w ""$user"" /usr/local/etc/mpd5/bandwidth.conf | cut -d" = " -f2` #grab max inbound throughput=0A= outkbps=3D`grep -w ""$user"" /usr/local/etc/mpd5/bandwidth.conf | cut = -d" " -f3` #grab max outbound throughput=0A= if [ -z $usernum ]; then #if no usernum=0A= currentusers=3D`wc -l /usr/local/etc/mpd5/bandwidth.conf | cut -d " " = -f8` =0A= #count the lines in the file=0A= usernum=3D`expr $currentusers + 1` #add one to the count of lines=0A= echo newusernum: $usernum=0A= fi=0A= =0A= if [ -z $outkbps ]; then #if no inkbps, default to 1024kbps=0A= outkbps=3D1024=0A= echo newoutkbps: $outkbps=0A= fi=0A= if [ -z $inkbps ]; then #if no outkbps, default to 1024kbps=0A= inkbps=3D1024=0A= echo newinkbps: $inkbps=0A= fi=0A= pipein=3D`echo $usernum*2 | bc` #the firewall pipe and rule numbers=0A= pipeout=3D`expr $pipein + 1` #get seeded by the usernumber=0A= fwrulein=3D`expr $pipein + 1000`=0A= fwruleout=3D`expr $fwrulein + 1`=0A= fwholein=3D`expr $pipein + 33000`=0A= fwholeout=3D`expr $fwholein + 1`=0A= $fwcmd pipe $pipein config bw ${inkbps}Kbit/s=0A= #make an inbound pipe of the right size=0A= $fwcmd pipe $pipeout config bw ${outkbps}Kbit/s =0A= #same for outgoing=0A= #$fwcmd add $fwrulein pipe $pipein ip from any to $clientip in = =0A= #force traffic through the correct pipe=0A= $fwcmd add $fwruleout pipe $pipeout ip from $clientip to any via $int =0A= #$fwcmd add $fwruleout pipe $pipeout ip from $clientip to any out =0A= #$fwcmd add $fwholein permit ip from any to $clientip =0A= #allow that traffic through firewall=0A= #$fwcmd add $fwholeout permit ip from $clientip to any =0A= echo `date`,$usernum,$user,$type,$clientip,$int,$inkbps,$outkbps >> = /var/log/mpd.output=0A= =0A= # -------------- end addclient.sh file ----------=0A= =0A= =0A= =0A= ------=_NextPart_000_0007_01CBB69C.C37A80D0-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 21 23:39:54 2011 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 097B9106564A for ; Fri, 21 Jan 2011 23:39:54 +0000 (UTC) (envelope-from nobody@cgi32.plala.or.jp) Received: from wns1.plala.or.jp (wns1.plala.or.jp [60.43.63.12]) by mx1.freebsd.org (Postfix) with SMTP id 804398FC08 for ; Fri, 21 Jan 2011 23:39:53 +0000 (UTC) Received: (qmail 14191 invoked from network); 22 Jan 2011 07:39:38 +0900 Received: from unknown (HELO cgi32.plala.or.jp) (60.43.59.232) by 0 with SMTP; 22 Jan 2011 07:39:38 +0900 Received: (from nobody@localhost) by cgi32.plala.or.jp (8.13.7/8.13.7/Submit) id p0LMdbDn001495; Sat, 22 Jan 2011 07:39:37 +0900 Date: Sat, 22 Jan 2011 07:39:37 +0900 Message-Id: <201101212239.p0LMdbDn001495@cgi32.plala.or.jp> To: freebsd-ipfw@freebsd.org From: WESTERN UNION MONEY TRANSFER MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: PICK UP YOUR $5,000.00USD X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: western_u675@hotmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 23:39:54 -0000 ATTN: Beneficiary, The western union is using this medium to appreciate their valued customer with a new year compensatory fund of $8,000,000 US Dollars, so this notification is only meant for people that have use western union, in receiving and sending money. Dear I write to inform you that we have deposited your compensatory funds of $8,000,000 USD through Western union Office for Immediate transfer the arrangement is that you will be receiving $5,000.00USD daily until your total funds is completely transfered to you,Please pick up this information and locate any western union (OUTLET) in your country and pick up this $5,000.00USD and send us an email back,so that we can send another $5,000.00USD by tomorrow. Manager: Mr Frank Amos Email us on: western_u675@hotmail.com once you picked up this $5,000.00USD today. Here is the western union information to pick up the $5,000.00USD, MTCN : 379 231 5601 Sender's Name: ojo agbata Question: Honest Answer:Trust Amount sent: $5,000.00USD country:Nigeria I am waiting for your E-mail once you pickup this $5,000.00USD, Thanks Mr Frank Amos