Re: kern/97504: [ipfw] IPFW Rules bug

The following reply was made to PR kern/97504; it has been noted by GNATS. From: Oliver Fromme To: bug-follo...@freebsd.org, freebsd-ipfw@FreeBSD.org, marcelo...@hotmail.com (Marcelo Machado) Cc: Subject: Re: kern/97504: [ipfw] IPFW Rules bug Date: Wed, 4 Aug 2010 15:38:13 +0200 (CEST

Re: kern/97504: [ipfw] IPFW Rules bug

rse-lookup. Do you agree that the PR can be closed? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht

Re: Small problem with "ipfw list"

Luigi Rizzo wrote: > On Mon, Mar 15, 2010 at 07:57:24PM +0100, Oliver Fromme wrote: > > Do you think this could be merged to stable/8 and stable/7? > > it's a trivial change to the userland program so whoever wants > to do the merge is welcome. I should be ab

Re: Small problem with "ipfw list"

Luigi Rizzo wrote: > On Tue, Mar 09, 2010 at 03:36:15PM +0100, Oliver Fromme wrote: > > Hi, > > > > Just a question: Is the output from "ipfw list" supposed > > to be in the same rule format that is accepted as input? > > If that's the ca

Re: Small problem with "ipfw list"

Luigi Rizzo wrote: > On Tue, Mar 09, 2010 at 03:36:15PM +0100, Oliver Fromme wrote: > > Just a question: Is the output from "ipfw list" supposed > > to be in the same rule format that is accepted as input? > > it is not, partly due to backward compatibility.

Small problem with "ipfw list"

e word "dst-ip" in the output when an "or" block is used, but that word isn't accepted as input. I think the output from "ipfw list" should be valid rule format that could be fed back as input to ipfw(8). In fact that's exactly what I need to do in a sc

Re: keep-state rules inadequately handles big UDP ??packets?or?fragmented IP packets?

Dmitriy Demidov wrote: > Oliver Fromme wrote: > > I'm just curious ... Is it really worth the effort to add > > fragment reassembly to IPFW? What advantage does it have? > > > > It would be much easier to simply pass all fragments with > > offset >

Re: keep-state rules inadequately handles big UDP ?packets?or?fragmented IP packets?

at would be the problem with this approach? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mü

Re: FreeBSD 7.0: dummynet 99% cpu

table. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik

Re: ipfw (dummynet) adds delay, but not configured to do so

and 0.1 ms on 100 Mbit. Voila. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Gesc

Re: in-kernel nat and stateful inspection hangs system 7.1 RELEASE

esponse. No logs can be observed. > > When i remove all skipto and checkstate rules, system work properly without > problems. I suspect about stateful inpection code. If you don't have an explicit check-state rule, then there's an implicit check-state rule at the first keep

IPFW performance on SMP (vs. PF)

r? Thanks for any insights. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- ch

Re: ipfw table bad command

Jin Fang <[EMAIL PROTECTED]> wrote: > I have now upgraded freebsd to 5.4-RELEASE-p8. > But still, I have problem when using "ipfw table" > ipfw:bad command `table' Are you sure you're using the right executable? Try /sbin/ipfw instead. Best regards Oliver

Re: Features enhacement: AND-block and "me" expression on a table...

quot;skipto" also often improves performance of the rule set, because fewer rules have to be analyzed for every packet. If you have a lot of rules, it is almost always a good idea to group them into logical units and then use "skipto" to jump into the appropriate groups. Doing tha

Re: String Match

to follow it. As Max pointed out, you can achieve the same in various ways (divert, bpf, pfil, netgraph), which are much better suited for that job. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http:/

Re: String Match

untrusted users? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions o

Re: String Match

(e.g. apache). That's not the job of a packet filter. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the auth

Re: Enable ipfw without rebooting

#x27;s exactly the same thing. When changing the rules, the same three cases can happen which I enumerated above: It works, or it locks you out because of the rules, or the machine crashes. (Although -- hopefully -- the crash case should be rather unlikely.) Best regards Oliver -- Oliver

Re: Enable ipfw without rebooting

Ganbold <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > [...] > > For changing (and testing) rules, there's an even more > > elegant (and non-[qddisruptive) solution, see: > > /usr/share/examples/ipfw/change_rules.sh > > If you want to res

Re: Enable ipfw without rebooting

Achim Patzner <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > No. Performing a reboot is a rather bad idea. > > Actually _loading kernel modules you haven't been using before_ Lots of people have been using it before. (Personally I prefer to compile i

Re: Enable ipfw without rebooting

y" | at + 5 minutes # kldload ipfw The same procedure is also useful when activating untested changes to the IPFW rule sets. If everyting went well and you didn't get disconnected, use atrm(1) to remove the "at" job. Best regards Oliver -- Oliver Fromme, secnetix GmbH &

Re: Enable ipfw without rebooting

is generate a error: > > ‰sysctl: unknown id 'net.inet.ip.fw.enable' Do you have IPFW code in your kernel? (Either statically compiled via kernel config, or dynamically loaded as KLD) If you don't, then it doesn't work, of course. Try loading the IPFW KLD ("kld

Re: multiple incoming lines

not sure what you actually want to do. Do you want to use your two uplinks in a load-balancing fashion? That's not possible when using different ISPs for your uplinks (even with the same ISP it's difficult). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz

Re: in via or in recv

detail in the ipfw(8) manpage. > When need to use an variant or another? That depends on what you want to do. In my experience there is rarely a need for "via". Usually you only need "recv" and "xmit" (optionally combined with "in" and "out" as ap

Re: IPFW ip masking and stateful connections

roadcasts on 255.255.255.255 port 60001. The only thing using that port (AFAICT) is a trojan called Trinity. So is it your intention to broadcast that trojan to the whole internet? :-) The following rules have similar issues as those already mentioned above, so I won't repeat it. Best re

Re: Another bug in IPFW@ ...?

AT Matik <[EMAIL PROTECTED]> wrote: > On Wednesday 03 August 2005 06:19, Oliver Fromme wrote: > > > > > out and xmit is probably exactly the same > > > > No, it's not. "out" just says that this rule matches only > > outgoing pack

Re: Another bug in IPFW@ ...?

not recv any' feature, too. At the moment I use > a static list. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secne

Re: Another bug in IPFW@ ...?

AT Matik <[EMAIL PROTECTED]> wrote: > On Tuesday 02 August 2005 14:46, Oliver Fromme wrote: > > > P.S. looks very strange "out not recv any xmit" > > > > It's perfectly valid syntax according to ipfw(8). > > (1+1-1)/1 also ... ;) I s

Re: Another bug in IPFW@ ...?

not reboot this router any time (ipfw is configured statically in the kernel). Thanks again, Luigi, I appreciate your assistance! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and

Re: Another bug in IPFW@ ...?

Sten Daniel Sørsdal <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > However, the problem is that the second option is being > > ignored, and I would like to know why, and how to work- > > around the bug. > > Would this work?: > > # ipfw add

Re: Another bug in IPFW@ ...?

uot;recv any", see the ipfw(8) manpage. 3. "xmit dc0" --> match packets which are going to be transmitted through the dc0 interface. However, the problem is that the second option is being ignored, and I would like to know why, and how to work- around the bug. Best regards

Another bug in IPFW@ ...?

, exluding $A. For example: $A = 101.102.103.1 $N = 101.102.103.0/27{2-30} PPS: I read the mailing list, so please do not Cc me. -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflec

Re: Most wanted packet filter

Since pf is nearly a superset of ipf with similar syntax and improved features, I recommend to use pf instead. Or ipfw, of course. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the auth

Re: Trying to understand dynamic rules

then fix them first, because blackholing IPs won't save you anyway. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix

Re: "or" blocks in IPFW2

Luigi Rizzo <[EMAIL PROTECTED]> wrote: > On Wed, Jul 13, 2005 at 05:57:53PM +0200, Oliver Fromme wrote: > ... > > # ipfw add allow tcp from any to any \{ in recv fxp0 or out xmit fxp0 \} > > 04400 allow tcp from any to any in { recv fxp0 or out } xmit fxp0 > >

"or" blocks in IPFW2

rent which doesn't even make any sense. Most confusingly, I don't get an error message or even a warning from the parser. Is this a bug in ipfw, or a bug in the manpage, or do I just misunderstand things? Do I have to write two separate rules? Thanks in advance! Best regards Oliver --