From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 13 11:52:53 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7710CB6E; Mon, 13 Oct 2014 11:52:53 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEEA292B; Mon, 13 Oct 2014 11:52:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s9DBqeq5044192; Mon, 13 Oct 2014 22:52:40 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 13 Oct 2014 22:52:40 +1100 (EST) From: Ian Smith To: Hiroki Sato Subject: Re: net.inet{,6}.fw.enable in /etc/rc In-Reply-To: <20141012.050211.468265599523763400.hrs@allbsd.org> Message-ID: <20141013202423.J56328@sola.nimnet.asn.au> References: <542155FB.9020801@freebsd.org> <20141002.163913.1611863032602700090.hrs@allbsd.org> <20141003025830.D48482@sola.nimnet.asn.au> <20141012.050211.468265599523763400.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20141013202423.I56328@sola.nimnet.asn.au> Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 11:52:53 -0000 On Sun, 12 Oct 2014 05:02:11 +0900, Hiroki Sato wrote: > Ian Smith wrote > in <20141003025830.D48482@sola.nimnet.asn.au>: > > sm> which rules will be flushed when /etc/rc.d/ipfw runs, but should enable > sm> DHCP to work? I'm not sure whether those rules are exactly correct or > sm> sufficient for DHCP, but principle is to anly allow what's necessary in > sm> the circumstances this addresses, vastly reducing vulnerable window. > sm> > sm> Using such a method, there should be no need to modify rc.d/ipfw? > > I created an experimental patch based on an idea installing a minimal > ruleset. Please review the attached patch. rc.d/ipfw0 script to > install such a ruleset is invoked before rc.d/netif. The following > two knobs are added: > > $firewall_minimal_rules_enable > Enable/disable installing a minimal ruleset. > > $firewall_minimal_ruleset > Ruleset number to be used for the ruleset. Hi Hiroki. Comments below. > sm> > Does ipfw have rules which depend on interface initialization? If > sm> > not, moving rc.d/ipfw to just before rc.d/netif may be a better idea. > sm> > sm> It can. If using (say) mpd with dialup or ADSL modems, as I do, the > sm> interface - here ng0 - needs to preexist, needing an IP address too. > sm> > sm> I think that by now, many will likely rely on netif preceding ipfw. > > AFAICC an IPFW rule for ng0 can be installed before the interface is > created. Do you have a specific rule which is problematic if IPFW > rules are loaded before rc.d/netif runs? I am also using mpd and a > lot of cloned interfaces on my router box but it worked fine. That's probably right. That box switched to mpd at 4.1, having run ppp for a long time previously. /etc/rc.d/ppp always had # REQUIRE: netif ppp has possibly changed a lot since I last used it, so I don't know if that's really still required; probably, unless architecture has changed. Anyway, looking at rcorder /etc/rc.d/* there are quite a few possible interdependencies to explore before considering moving ipfw, including its relationship to pf - some people do use both - and perhaps routing, bridge, defaultroute, among others? Hard to imagine all usage cases .. I think your patch adds some unnecessary complexity to what should be needed to solve this fairly singular problem of the firewall being in kernel or loaded early, default to deny, with DHCP (etc) access needed before netif can succeed. I like the general idea of running ipfw0 (ono) earlier to enable needed rules in this specific context - perhaps also testing whether rc.conf indicates that DHCP (or ipv6 equivalents, about which I know nothing) is actually required on at least one of the to-be-configured interfaces? I don't think it's necessary to use a special set, set 0 would be fine as any firewall script will begin with a flush anyway. I don't think this function need require any user configuration at all, if possible, as it really is coping with an (albeit important) edge case. Couldn't proposed additions to rc.firewall just go into rc.d/ipfw0? Can you explain why any layer2 rules are needed specifically? Apart from testing for dest mac ff:ff:ff:ff:ff:ff as well as 255.255.255.255/32 on the first rule, maybe overkill?, can't all these rules be run at layer3? For one thing, if running L2 routing (and/or bridging), it's long been practice and advice to set net.link.ether.ipfw (&| net.link.bridge.ipfw) in /etc/sysctl.conf, and sysctl is run early .. on 9.3, first. This way you'll have to get people to update L2 configs to use this new firewall_link_enable variable as well or instead. If L2 is really necessary, perhaps the previous setting of net.link.ether.ipfw could be remembered by ipfw0 and exported for rc.d/ipfw, seeing this is currently the only change to rc.d/ipfw, apart from clearing of the temporary rules - which I believe the subsequent flush makes unnecessary anyway. Just some thoughts, cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 13 16:55:32 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CFED689; Mon, 13 Oct 2014 16:55:32 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 702CFF74; Mon, 13 Oct 2014 16:55:31 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9DGt7NY021279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Oct 2014 01:55:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9DGt5Z8035882; Tue, 14 Oct 2014 01:55:06 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 14 Oct 2014 01:49:36 +0900 (JST) Message-Id: <20141014.014936.1483336189189184574.hrs@allbsd.org> To: smithi@nimnet.asn.au Subject: Re: net.inet{,6}.fw.enable in /etc/rc From: Hiroki Sato In-Reply-To: <20141013202423.J56328@sola.nimnet.asn.au> References: <20141003025830.D48482@sola.nimnet.asn.au> <20141012.050211.468265599523763400.hrs@allbsd.org> <20141013202423.J56328@sola.nimnet.asn.au> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct_14_01_49_36_2014_368)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Tue, 14 Oct 2014 01:55:25 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:55:32 -0000 ----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Smith wrote in <20141013202423.J56328@sola.nimnet.asn.au>: sm> Anyway, looking at rcorder /etc/rc.d/* there are quite a few possible sm> interdependencies to explore before considering moving ipfw, including sm> its relationship to pf - some people do use both - and perhaps routing, sm> bridge, defaultroute, among others? Hard to imagine all usage cases .. I do not think ordering of ipfw and pf is important. Configuration of routes and others can depend on netif, but not on ipfw and other packet filters. One possible obstacle is a packet filter rule requires ifname or ifindex before the rule is added. IPFW does not have such restriction, though. sm> I like the general idea of running ipfw0 (ono) earlier to enable needed sm> rules in this specific context - perhaps also testing whether rc.conf sm> indicates that DHCP (or ipv6 equivalents, about which I know nothing) is sm> actually required on at least one of the to-be-configured interfaces? sm> sm> I don't think it's necessary to use a special set, set 0 would be fine sm> as any firewall script will begin with a flush anyway. I don't think sm> this function need require any user configuration at all, if possible, sm> as it really is coping with an (albeit important) edge case. sm> sm> Couldn't proposed additions to rc.firewall just go into rc.d/ipfw0? I think such a testing is more complex in practice from my experience with improving network.subr. Users who want the default-deny rule at boot time should be strict about the rule set. So, I want to make clear what rules are applied and make it configurable, and then set it to a reasonable default which allow only DHCPv4 and IPv6 DAD. This is the reason why I use rc.firewall. And, rc.d scirpts must be as consistent as possible in terms of behaviors on start and stop. "ipfw set" is easiest way to remove the minimal rule set upon stop. These implementation choices are not harmful or complex for normal users after all in my opinion. Even if we need dynamically-added rules depending on configuration in the future, it can be supported easily in this framework. sm> Can you explain why any layer2 rules are needed specifically? Apart from sm> testing for dest mac ff:ff:ff:ff:ff:ff as well as 255.255.255.255/32 on sm> the first rule, maybe overkill?, can't all these rules be run at layer3? L3 rule cannot catch the outgoing DHCPDISCOVER with the source address 0.0.0.0 and the destination address 255.255.255.255. You can try this on your box. sm> For one thing, if running L2 routing (and/or bridging), it's long been sm> practice and advice to set net.link.ether.ipfw (&| net.link.bridge.ipfw) sm> in /etc/sysctl.conf, and sysctl is run early .. on 9.3, first. sm> sm> This way you'll have to get people to update L2 configs to use this new sm> firewall_link_enable variable as well or instead. If L2 is really sm> necessary, perhaps the previous setting of net.link.ether.ipfw could be sm> remembered by ipfw0 and exported for rc.d/ipfw, seeing this is currently sm> the only change to rc.d/ipfw, apart from clearing of the temporary sm> rules - which I believe the subsequent flush makes unnecessary anyway. Ah, I see. I agree with this. I will update the patch. -- Hiroki ----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQ8AqAACgkQTyzT2CeTzy1UugCfX4XGbbnFoGKv/at2L4ygZeHG pyQAn33ZhSPiJsBYP1b9lRMUujmfufgC =mnmp -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)---- From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 13 21:53:28 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2210720 for ; Mon, 13 Oct 2014 21:53:28 +0000 (UTC) Received: from m.nyi.net (m.nyi.net [66.111.12.250]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97D0D65D for ; Mon, 13 Oct 2014 21:53:28 +0000 (UTC) Received: from m.nyi.net (localhost [127.0.0.1]) by m.nyi.net (Postfix) with ESMTP id B9936108997 for ; Mon, 13 Oct 2014 17:46:20 -0400 (EDT) Received: from m.nyi.net ([127.0.0.1]) by m.nyi.net (m.nyi.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enq8rFI8SyzY for ; Mon, 13 Oct 2014 17:46:12 -0400 (EDT) Received: from [10.50.50.227] (urchin.nyi.net [64.147.100.2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jacob@nyi.net) by m.nyi.net (Postfix) with ESMTPSA id 06B70108994 for ; Mon, 13 Oct 2014 17:46:11 -0400 (EDT) Message-ID: <543C4825.6030901@nyi.net> Date: Mon, 13 Oct 2014 17:46:13 -0400 From: Jack Barber Organization: New York Internet Company User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: FreeBSD max pipe size? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:53:28 -0000 I am trying to set up dummynet with FreeBSD 9.3 and a 10 GB Fibre over ethernet NIC (ix drivers). Dummynet appears to have a limit of 1.25 gigabits a second, and when I start setting extremely large pipe values I start running into: ipfw: bandwidth too large It doesn't like(in /etc/ipfw.rules) $IPFWcmd pipe 10 config bw 8000Mbits but for some reason it likes $IPFWcmd pipe 20 config bw 100000Mbits and $IPFWcmd pipe 10 config bw 10000Mbits even if there is no notcable performance diffrence betwen them $ iperf -c load-server2 ------------------------------------------------------------ Client connecting to load-server2, TCP port 5001 TCP window size: 434 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.20.25 port 56122 connected with 192.168.20.20 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.57 GBytes 1.35 Gbits/sec $ iperf -c load-server1 ------------------------------------------------------------ Client connecting to load-server1, TCP port 5001 TCP window size: 459 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.20.20 port 49028 connected with 192.168.20.25 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.36 GBytes 1.17 Gbits/sec testing is done on a private subnet which houses nothing more than two loading servers and a FreeBSD bridge in between. All machines have 10 GB/sec ix driver cards. Now, same set up, but commenting out all dummynet refrences in ipfw.rules: $ iperf -c load-server1 ------------------------------------------------------------ Client connecting to load-server1, TCP port 5001 TCP window size: 459 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.20.20 port 49029 connected with 192.168.20.25 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 8.44 GBytes 7.24 Gbits/sec $ iperf -c load-server2 ------------------------------------------------------------ Client connecting to load-server2, TCP port 5001 TCP window size: 434 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.20.25 port 56123 connected with 192.168.20.20 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 7.89 GBytes 6.78 Gbits/sec From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 13 22:13:55 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 149B5166 for ; Mon, 13 Oct 2014 22:13:55 +0000 (UTC) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5B1B8C0 for ; Mon, 13 Oct 2014 22:13:54 +0000 (UTC) Received: by mail-oi0-f43.google.com with SMTP id u20so14451126oif.2 for ; Mon, 13 Oct 2014 15:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g3eJSx9pbVbWK9qRGKZn7FwDQ0Q8nEMAHMlSuPtooIA=; b=LW+a1npOZ8KL3dznkopIogk5CkzwM/fNYXKNKgP2MCgSYq4FD6cOjCJkos0J09Rxvd Me4it2gW5n7WBt6ntasXt0M7mBApQw6Jx9wFfhvm/+06okWamHR8awB+iBfcrYLXppDs jbUmaeJhCLjKLWWYw6eVKq6+H6t1oDJPg2ksV0o9UxtD8hKPHiPQ6kImvIitRtHuYB2g jXBCso3Fuxig64qBxXIuHeFQ3TEebLGu2SRAV0taDSTEyydYp3R0S3p9y2LvdM2lnDTN Bsk3/hhArwhexoru+2/G4yDsjHwkRG7s8kUWMP7lZ6SDzk/GRX4PqfE0PBno3zrzY5ji Igpg== X-Gm-Message-State: ALoCoQnAr/iOFxiBfnaTwmjb6fFSfw7JXMISqlj+h7HKFVBXl5tjZgWzez3L7hvFwijWJeN7WeMF MIME-Version: 1.0 X-Received: by 10.182.245.225 with SMTP id xr1mr1071897obc.13.1413238428481; Mon, 13 Oct 2014 15:13:48 -0700 (PDT) Received: by 10.60.220.134 with HTTP; Mon, 13 Oct 2014 15:13:48 -0700 (PDT) In-Reply-To: <543C4825.6030901@nyi.net> References: <543C4825.6030901@nyi.net> Date: Mon, 13 Oct 2014 15:13:48 -0700 Message-ID: Subject: Re: FreeBSD max pipe size? From: Michael Sierchio To: Jack Barber Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-ipfw@freebsd.org" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:13:55 -0000 On Mon, Oct 13, 2014 at 2:46 PM, Jack Barber wrote: > I am trying to set up dummynet with FreeBSD 9.3 and a 10 GB Fibre over > ethernet NIC (ix drivers). > > Dummynet appears to have a limit of 1.25 gigabits a second, and when I > start setting extremely large pipe values I start running into: > > ipfw: bandwidth too large > > It doesn't like(in /etc/ipfw.rules) > $IPFWcmd pipe 10 config bw 8000Mbits > but for some reason it likes > $IPFWcmd pipe 20 config bw 100000Mbits > and > $IPFWcmd pipe 10 config bw 10000Mbits Show your ruleset. In particular - are you using separate pipes for up and down, and do your rules properly segregate traffic? Do you actually only pass traffic into each pipe exactly once? I.e. do your rules read like ipfw add pipe 10 from any to any in recv $ext_if ipfw add pipe 20 from any to any out xmit $ext_if ? - M From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 13 22:15:35 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A29C302 for ; Mon, 13 Oct 2014 22:15:35 +0000 (UTC) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 664748DF for ; Mon, 13 Oct 2014 22:15:35 +0000 (UTC) Received: by mail-oi0-f43.google.com with SMTP id u20so14454919oif.2 for ; Mon, 13 Oct 2014 15:15:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9eWvLmDeZLDZQ76DZDtoNdWax2ey1vRVOzEeQNvYnCA=; b=NpoqVNGnZ0BTQ8bZI62JhXXKvD9NcQsWb+KrYjpPAs42NzisxYYh7Zrmvpp1RM0FHW 6dS/ZbmEKzRLEtM9Li7utfCDyU0PcbIe8JJpbRnjRI/bHtC4UHuX/46YSqz5bQL0KD93 tHFVDYIfgSyuM1nX+qkKSnkiLHKWySKozu/gkkDWcUxlT0neXL1QetCejIJF7tSYAWuY 26fnqF3c9Zym4QvAlAlCzEpMwDyvVGiNiKl5azOF/QoHKYFCFOosVzKVr9mZVtfasMGV jAs+iZMYsvKH+DsbTj3aeK5umnmLXuyGOYbCI3SXJgZCb5U0dXkwUnl25r2i7Xl+/gWM vnOQ== X-Gm-Message-State: ALoCoQmIxUkxUv8/+w0ywqyprVskZ0V92N9pP3llFUZckBZcJrMcf+MQZk8P4snow9Sb3UNzjdUE MIME-Version: 1.0 X-Received: by 10.202.3.70 with SMTP id 67mr897337oid.69.1413238534670; Mon, 13 Oct 2014 15:15:34 -0700 (PDT) Received: by 10.60.220.134 with HTTP; Mon, 13 Oct 2014 15:15:34 -0700 (PDT) In-Reply-To: References: <543C4825.6030901@nyi.net> Date: Mon, 13 Oct 2014 15:15:34 -0700 Message-ID: Subject: Re: FreeBSD max pipe size? From: Michael Sierchio To: "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:15:35 -0000 On Mon, Oct 13, 2014 at 3:13 PM, Michael Sierchio wrote: > ipfw add pipe 10 from any to any in recv $ext_if > ipfw add pipe 20 from any to any out xmit $ext_if Obviously a scrivener's error, and meant ipfw add pipe 10 ip from any to any in recv $ext_if ipfw add pipe 20 ip from any to any out xmit $ext_if From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 15 21:08:39 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEB1AE10 for ; Wed, 15 Oct 2014 21:08:39 +0000 (UTC) Received: from mail-pd0-x244.google.com (mail-pd0-x244.google.com [IPv6:2607:f8b0:400e:c02::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8269310B for ; Wed, 15 Oct 2014 21:08:39 +0000 (UTC) Received: by mail-pd0-f196.google.com with SMTP id ft15so712422pdb.11 for ; Wed, 15 Oct 2014 14:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:mime-version:to:reply-to:subject:content-type :content-transfer-encoding; bh=9agDyBVxaUz7HZXjUzgiGemeqaeiXxy1WOQI6iFDenM=; b=azWsClakJ7bc7gaw+kR1vo2X8dGxV9YFqFGAPTxzXiaiCRcNjWTHwgYpLRsFsh7QVe c23rK+lYRSkoyxY0IX0wIQ9KX4uD04xK93lNLxYiYSQyWs4E3TU6q2IcbZyj1TPObXC4 8cDnKiqWsOkKwGMfhw4wrhYT/VJDuTt7ivgK0WfKBKm7E+OYLGKgakNIXJ6kGJyM6bfD 92MBeZ7o3Zon4NhWYWFB7oW65Ct1dLumg/Mz3zhILPyqdPvE+JjtnduZqx8V4/90x6tR 070g+yXh+qI6ZCb8iOavDOgBI6BpX7N6PhmnzosHhHNsyHLiDUsiL8XeRKey8u9blOKb Y6cA== X-Received: by 10.68.134.230 with SMTP id pn6mr15495501pbb.88.1413407318871; Wed, 15 Oct 2014 14:08:38 -0700 (PDT) Received: from Inder-PC ([27.255.188.64]) by mx.google.com with ESMTPSA id gz1sm17942916pbb.8.2014.10.15.14.08.36 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Oct 2014 14:08:37 -0700 (PDT) Message-ID: <543ee255.216b440a.1b15.14f3@mx.google.com> Date: Wed, 15 Oct 2014 14:08:37 -0700 (PDT) X-Google-Original-Date: 16 Oct 2014 02:38:40 +0530 From: lori76557@googlemail.com X-Google-Original-From: LORI76557@gmail.com To: freebsd-ipfw@freebsd.org Reply-To: limpid75154@gmail.com Subject: Has your website : mail-archive.com been penalized by Google ? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 21:08:39 -0000 Good Morning Bussiness Owner Has your website lost traffic or rankings in last few weeks ? If yes, then your website is a VICTIM to these NEW google algorithm updates. To correct this you need to hire a professioanl Search Engine Optimization company who understands these changes better than what you can. More with these new updates coming each month you need your online web presence to be taken care by a group of SEO Experts who are dedicated to learn all these new changes coming their way. We are presently offering a 15 days FREE Trial for our S.E.O Service, so that you can experience our expert S.E.O skills and then decided to sign up with us. Our S.E.O Plans start from just 199$ and go to 399$ / month making sure your website is optimized for all possible keywords and not just 10-20 keywords like other companies offer. Google has recently launched 3 Big updates and refreshes keep coming every month 1) Google Panda Update : Targeting Websites with Bad ONSITE 2) Google Penguin : Targeting Websites with Bad backlinks 3) Google Pigeon : Targeting Websites with bad local presence We have helped our clients pass all these algorithms pass these updates in last 3 years and we are one of those few ONLY SEO companies who have not been affected MUCH by these updates. What makes our company different : 1) We optimize website not keywords : ( We optimize your website for as many keywords possible ) 2) We assure results in first 15 days itself 3) We have the best possible pricing on the web 4) We abide by all google rules 5) Every link built is shared with for your future use 6) We Offer complete SEO Service not just LINK BUILDING Email us back with your website and your phone number so we can study your website and email you back with our Customized proposal. Looking forward working with you. Regards Vince G SEO Manager ( TOB ) Skype ________________________________________ NO CLICK in the subject to STOP EMAILS