On Mon, 27 Sep 2010, c0re wrote:
Is there any possibility to see IPFIREWALL_FORWARD option for ipfw.ko
in GENERIC?
Were there any patches about that?
I like freebsd-update, but lacking IPFIREWALL_FORWARD in GENERIC stops
me from using freebsd-update.
In a nutshell, no. This thread
On Thu, 5 Aug 2010, Michael wrote:
Am I right thinking that if interface and reset parameters should be
enough to handle changing address (DHCP) on external interface?
In theory.
My rules:
ipfw -q nat 1 config reset if $if_ext log same_ports
ipfw -q add nat 1 udp from $jail_ip to
On Thu, 22 Jul 2010, Spil Oss wrote:
On Thu, Jul 22, 2010 at 12:16 PM, Ian Smith smi...@nimnet.asn.au wrote:
This points to a number of issues, not least the effect of people being
led to using the currently dreadful IPFW section of the handbook, which
contains so many conceptual
On Mon, 19 Jul 2010, Mamontov Roman wrote:
Hello, Ian.
UDP port 33564 on this box (xxx.xxx.xxx.xxx) is not redirected to any
other address:port, and you have specified deny_in (-deny_incoming in
natd-speak) so, well, you got what you asked for ..
See the description under
On Mon, 19 Jul 2010, Mamontov Roman wrote:
What's the value of sysctl net.inet.ip.fw.one_pass ? It needs to be 0
so that packets will re-enter the firewall after NAT processing.
Otherwise, it might help to
a) run 'ipfw zero' before any tests .. I'm wondering about all those
The following reply was made to PR conf/148144; it has been noted by GNATS.
From: Ian Smith smi...@nimnet.asn.au
To: bug-follo...@freebsd.org, naylor.b.da...@gmail.com
Cc:
Subject: Re: conf/148144: [patch] add ipfw_nat support for rc.firewall simple
type
Date: Sun, 27 Jun 2010 18:29:38 +1000
Hi .. as suggested, posting this discussion to ipfw@ too .. thanks, Ian
-- Forwarded message --
Date: Mon, 21 Jun 2010 13:00:14 +0200
From: Luigi Rizzo ri...@iet.unipi.it
To: Ian Smith smi...@nimnet.asn.au
Subject: Re: Online gaming and file downloads - latency hell! (fwd)
On Mon
The following reply was made to PR kern/132553; it has been noted by GNATS.
From: Ian Smith smi...@nimnet.asn.au
To: bug-follo...@freebsd.org
Cc: cwf...@arcor.de
Subject: Re: kern/132553: [ipfw] ipfw doesn't understand ftp-data port
Date: Tue, 13 Apr 2010 01:42:36 +1000 (EST)
Cristoph, the need
On Thu, 1 Apr 2010, Luigi Rizzo wrote:
On Wed, Mar 31, 2010 at 03:47:49PM -0300, Ass.Tec. Matik wrote:
it means that you are probably using a new kernel and an old /sbin/ipfw.
The new ipfw/dummynet has a different kernel/userland API to accommodate
some new features, and the
On Thu, 11 Mar 2010, n j wrote:
A loadable module requires a coherent piece of code to implement the
functionality, that can be put into the module. This option
scatters tiny snippets of code throughout the exisitng
TCP/UDP/IP/ipfw code.
Is that just a matter of current
On Fri, 16 Oct 2009, Chris St Denis wrote:
This is definitely a regression in 7.2.
Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test
server back to 7.2 and the messages come back.
I notice neither your rules shown below nor the workstation rules -
unlike the
On Wed, 19 Aug 2009, Michael Spratt wrote:
Chuck Swiger wrote:
Hi--
On Aug 17, 2009, at 7:32 AM, Michael Spratt wrote:
Could not find answer to following question.
Given :
# pipe 1 config bw 1Mbit/sec
# ipfw 1000 add pipe 1 ip from any to any out xmit em0
On Thu, 4 Jun 2009, Freddie Cash wrote:
Over the years, various how-tos and docs that I've read comparing ipfw
to ipf and pf have categorised them as such:
- ipf/pf compares the packet against every rule in the ruleset, and
the last matching action is used once the end of the ruleset
that despite 20 times the CPU clock rate,
probably at least 30 times CPU throughput and likely 10 times the tick
rate, you appear to be suffering something like 30 to 900 times the
increased latency to be expected by traversing 'too many' ipfw rules.
Ian Smith escreveu:
On Fri, 24 Apr 2009, Daniel
On Fri, 24 Apr 2009, Daniel Dias Gonçalves wrote:
The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms
Hardware:
CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU)
Logical CPUs per core: 2
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0:
The following reply was made to PR kern/129103; it has been noted by GNATS.
From: Ian Smith smi...@nimnet.asn.au
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:
Subject: Re: kern/129103: [ipfw] IPFW check state does not work =(
Date: Tue, 14 Apr 2009 00:01:07 +1000
I believe that I've
On Fri, 6 Mar 2009, Sebastian Mellmann wrote:
[.. after merciless snippage ..]
$cmd pipe 500 config bw $bottleneck_bandwidth
$cmd add pipe 500 all from any to any via $in_if
$cmd pipe 510 config bw $bottleneck_bandwidth
$cmd add pipe 510 all from any to any via $out_if
ipfw pipe
On Fri, 6 Mar 2009, Luigi Rizzo wrote:
On Fri, Mar 06, 2009 at 04:23:29PM +1100, Ian Smith wrote:
...
ipfw(8) at 7.1-RELEASE:
delay ms-delay
Propagation delay, measured in milliseconds. The value is
rounded to the next multiple of the clock tick (typically 10ms
On Thu, 5 Mar 2009, Sebastian Mellmann wrote:
If I configure another rule (or like 10 more rules) that matches the
packet, I can see the delay increasing.
For example a delay of ~20ms, when I configure 10 pipes.
Am I doing something wrong?
Configuring more pipes
On Thu, 5 Mar 2009, Sebastian Mellmann wrote:
Paired pipes will speed things up. Maybe not noticeably for pings (call
and response work half-duplex) but for esp TCP it could be considerable.
How does this pairing of pipes work?
Couldn't find any documentation about it?
Perhaps
On Wed, 4 Mar 2009, Sebastian Mellmann wrote:
I've got a IPFW ruleset that looks like this:
cmd=ipfw
bottleneck_bandwidth=100Mbit/s
in_if=em0
$cmd pipe 500 config bw $bottleneck_bandwidth
$cmd add pipe 500 all from any to any via $in_if
When I do a simple ping from one
On Wed, 18 Feb 2009, Roman Kurakin wrote:
n j wrote:
About 2 Minutes later after apply this rule set, system writes that bge1
watchdog timeout --- resetting and then system hangs, keyboard doesnt
response. No logs can be observed.
When i remove all skipto and checkstate
On Fri, 19 Dec 2008, Gloomy Group wrote:
Hello Ian,
I have implemented traffic shaping with dummy net pipe. But i want
to strictly control the internet sharing to single pc. Is there other
way of allowing like MAC address restricting to 2 pc coming from that
source ip.
Kes,
your message didn't make it to the list. Probably because of the 650KB
attached diagram :) Big stuff is better put up as an URL to a web site.
On Tue, 25 Nov 2008, KES wrote:
#ipfw -ed show
10 0 check-state log
22 120 count log icmp from any to any via ng0
On Sun, 16 Nov 2008, Jin Guojun[VFF] wrote:
Ian Smith wrote:
On Sat, 15 Nov 2008, Jin Guojun[VFF] wrote:
I think this is a bug in ipfw because after change the rule order, the
problem persists:
0056626 3090 deny ip from 221.192.199.36 to any
65330
On Fri, 14 Nov 2008, Julian Elischer wrote:
Julian Elischer wrote:
Ian Smith wrote:
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side
On Thu, 13 Nov 2008, Julian Elischer wrote:
At home I use the following change.
basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.
any objections?
Only that if people are already using tables for anything, chances are
they've
-- Forwarded message --
Date: Fri, 17 Oct 2008 05:24:43 +1100 (EST)
From: Ian Smith [EMAIL PROTECTED]
To: freebsd-ipfw@freebsd.org
Subject: Re: Speaking of rc.firewall ..
On Thu, 16 Oct 2008, Ian Smith wrote:
I see that both HEAD and RELENG_7 rc.firewall have been updated
On Wed, 15 Oct 2008, Lin Zhao wrote:
hi all
we have a simple network
|-|
internal network-| freeBSD |--public network
rl0/192.168.0.1|-|fxp0/a.b.c.1
I see that both HEAD and RELENG_7 rc.firewall have been updated for in-
kernel NAT functionality, but only for the 'open' and 'client' rulesets.
Is there any (functional) reason that the ${firewall_nat_enable} case is
not also included in the 'simple' rules, where its different placement
is
On Thu, 16 Oct 2008, Ian Smith wrote:
I see that both HEAD and RELENG_7 rc.firewall have been updated for in-
kernel NAT functionality, but only for the 'open' and 'client' rulesets.
Is there any (functional) reason that the ${firewall_nat_enable} case is
not also included
On Tue, 19 Aug 2008, Luigi Rizzo wrote:
On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote:
On Thu, 31 Jul 2008, Julian Elischer wrote:
...
ipfw add 1000 skipto tablearg ip from any to table(31)
...
see attached patch... (hopefully not stripped)
Of course
On Thu, 15 May 2008, Jeremy Chadwick wrote:
On Thu, May 15, 2008 at 11:03:53AM +0100, Bruce M. Simpson wrote:
Andrey V. Elsukov wrote:
Vivek Khera wrote:
I had a box run out of dynamic state space yesterday. I found I can
increase the number of dynamic rules by increasing the
101 - 133 of 133 matches
Mail list logo
