ci0 uhci1]
>
>
> It there a known workaround?
>
> Details:
> Machine : i386
> OS : FreeBSD 11.2-RELEASE-p10
> Command : ipfw set disable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 enable 16
> 17 18 19 20 21 22 23 24 25 26 27 28 29
>
Can't speak to this
dynamic connections.)
ipfw -f set 1 flush
ipfw set 1 disable
... all your normal rules, prepended by "set 1"
ipfw set enable 1
ipfw set swap 1 0
ipfw set disable 1
ipfw -f set 1 flush
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
ion of the rule (what goes after the interface). You can do just about
anything within that section, including a lot of what could be done in the
"protocol" and "source address" and "destination address" sections.
--
Freddie Cash
fjwc...@gmail.com
__
m any to $PRV_NET out xmit $IIF
# Block the rest
ipfw add deny log ip from any to any in recv $EIF
ipfw add deny log ip from any to any in recv $IIF
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freeb
On Thu, May 4, 2017 at 9:22 AM, Karl Denninger wrote:
> Consider the following network configuration.
>
>
> Internet --- Gateway/Firewall -- Inside network (including a
> web host)
> 70.16.10.1/28 192.168.0.0/24
>
> The address of the outside is FICTIONAL, by the way.
nding
on which you have first.
You'll need to set net.inet.ip.fw.one_pass=0 in order to re-inject the
packet into the rules after it matches a dummynet or NAT rule. Or, do the
NAT and dummynet rules on different interfaces to match different traffic.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
NAT across
networks using public IPs only). Optimisation work is just now beginning.
:)
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail
p=2
net.inet.ip.fw.enable=1
net.inet.ip.fw.one_pass=1
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=1
At lunch today, we'll be failing-over to the other firewall, which will be
running without any /boot/loader.conf or /etc/sysctl.conf entries to see if
my "optimisations&qu
ation allows you to load updated rules
without disconnecting anyone or dropping any packets:
disable set 1
load rules into set 1
enable set 1
swap set 1 0
disable set 1
I understand how everything works a little bit better now. Thanks for all
the help and pointers and discussion.
--
Fr
On Sep 14, 2014 3:37 AM, "Willem Jan Withagen" wrote:
>
> On 13-9-2014 21:51, Freddie Cash wrote:
> > You can replicate it using 3 rules, loaded into two sets:
> >
> > ipfw set disable 1
> > ipfw add allow ip from any to any
> > ipfw add 65524 allow
You can replicate it using 3 rules, loaded into two sets:
ipfw set disable 1
ipfw add allow ip from any to any
ipfw add 65524 allow ip from any to any
ipfw add allow ip from any to any
ipfw set swap 1 0
Run that two or 3 times. Every rule will be numbered 65534 after the 2nd or
3rd run.
I expect
Forgot to mention, this is 64-bit FreeBSD 10.0-RELEASE-p7, using Intel
i350-T4 (igb) NICs.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail
ax:
ipfw add set 1 allow tcp from 1.2.3.4 to 2.3.4.4 in recv igb0
Then swap the rules at the end using:
ipfw set swap 1 0
Is there anything I could be doing differently to get the numbering to work
the way I expect it to? Or am I going to have to manually number every
rule in my
; individual second. only the first 2 packets will be allow, all others in
> the same second will be dropped.
>
For ICMP, specifically, there's a sysctl to control the rate (per second):
# sysctl -d net.inet.icmp.icmplim
net.inet.icmp.icmplim: Maximum number of ICMP responses per sec
e lookup, get a result
2. Replace in main rule with result from lookup
3. Evaluate the rule and compare the packet to it.
Interesting. This would cleanup the syntax of my rules-creation scripts
and make it easier to manually type rules at the CLI.
Anyone feel like updating the man page to
(the tablearg). So where is the "lookup" getting src-ip/dest-ip/etc
from?
What's the difference between:
ipfw add 05000 skipto tablearg ip from any to me in recv $if_wan lookup
src-ip $table_number
ipfw add 05000 skipto tablearge ip from table\($table_number\) to my in
recv $if
On Mon, Jan 16, 2012 at 11:40 AM, Michael Sierchio wrote:
> On Mon, Jan 16, 2012 at 11:05 AM, Freddie Cash wrote:
>
>> Personally, I don't use skipto rules, as I find them to just cause
>> confusion. ...
>
> skipto rules are essential in numerous instances, espe
things like FTP connections.
It's a much smaller range.
There's also FTP NAT tracking modules for IPFW, but I've never
personally used any of them.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
tead.
The way dummynet works, is that pipes set hard limits on the bandwidth.
And queues provide minimum guarantees for bandwidth inside of that pipe.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org
LENG_8_0_0_RELEASE and then do another build/install cycle to fix the
> problem, or will the problem still be there?
>
> Also, I know this a volunteer effort so I have no right to be pushy, but is
> there any ETR on this so that I can start tracking RELENG_8 again?
>
Use RELENG_8_0.
ng a bunch of cleanups, refactoring, and updates to the ipfw
code in 8-STABLE/9-CURRENT. Things are a bit unstable right now, but
getting better with each passing day.
IOW, nothing to worry about unless you have plans to upgrade to 8-STABLE.
:)
--
Freddie Cash
fjwc...@gmail.com
ange the meaning of "me". "me" is any IP address
configured on any interface. In that sense, there shouldn't be any
differentiation between IPv4 and IPv6, since both are IP.
If we wanted to be pedantic and keep things consistent, then why isn't there
an "any
roxy server installed somewhere, that
Dansguardian will forward the requests to, and receive the responses
from.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
8 to any
> 00400 allow udp from me to any keep-state
> 65535 deny ip from any to any
>
>
If you add "out xmit em0" to the udp rule, do the errors stop?
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
That will match any IP
packets, regardless of what protocol data is inside the packet.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Okay, so my understanding was (mostly) correct. Thanks for the extra info.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "fr
rule processing ends
setup? Or does it check every single rule for every single packet?
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail t
.
Now to compress the rules a bit using this. :)
Thanks again, Luigi!!
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
On Thu, May 21, 2009 at 9:42 AM, Luigi Rizzo wrote:
> On Thu, May 21, 2009 at 08:49:30AM -0700, Freddie Cash wrote:
>> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote:
>> > On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>> >> can ipfw use somehow
On Thu, May 21, 2009 at 9:41 AM, Steve Bertrand wrote:
> Freddie Cash wrote:
>> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo wrote:
>>> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>>>> can ipfw use somehow interface groups as pf(4) can?
>>>
d firewalls where the only thing that's different is the
incoming interface has been a pain ...
Thanks for the info!!
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To
On March 4, 2009 11:17 pm Sebastian Mellmann wrote:
> >> > Is there any chance to change this clock tick to a lower value?
> >> > I think it's the 'HZ=' option in the kernel config isn't it?
> >>
> >> yes. i believe there is a tunable (so you don't need to rebuild
> >> the kernel) but i do not reme
On March 4, 2009 1:14 pm Luigi Rizzo wrote:
> On Wed, Mar 04, 2009 at 10:05:53PM +0100, Sebastian Mellmann wrote:
> > > On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote:
> > > the delay that a packet experiences corresponds to len/bandwidth,
> > > often rounded up to the next cloc
orks:
> divert natd any from 192.168.1.0/24 to any
> divert natd any from any to
Have you tried restricting your rules to only the vr1 interfaces, with
configured directly on vr1:
divert natd ip from 192.168.1.0/24 to any out xmit vr1
divert natd ip from any to in recv vr1
--
F
On Fri, March 30, 2007 4:45 pm, Julian Elischer wrote:
> Freddie Cash wrote:
>> On Friday 30 March 2007 01:40 pm, Julian Elischer wrote:
>>
>>> I have been looking at the IPFW code recently, especially
>>> with respect to locking. There are some things that co
ules to the script and reload them all. Keeps the
rules in memory in sync with the rules on disk.
Otherwise, no. :)
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
BSD 6.1-p6, i386 (P2 333 MHz box).
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
R i386 platform.
> Is there know problem on this issue? or Did I made some mistake?
>
> Please CC to me since I am not on the list.
Works fine here, with 62 deny rules out of 533 rules in total. While
not every deny rule has a matched packet so far, the rules under them
all work fine.
38 matches
Mail list logo
