On Thursday 02 April 2009, Paolo Pisati wrote:
> Luigi Rizzo wrote:
> > Ok then we may have a plan:
> >
> > you could do is implement REASS as an action (not as a microinstruction),
> > with the following behaviour:
> >
> > - if the packet is a complete one, the rule behaves as a "count"
> > (i.e
Luigi Rizzo wrote:
Can you put a description in the manpage especially on the
assumptions and side effects of the reass option ?
E.g. as i read it,
+ you need to make sure that the fragments are not dropped before
the 'reass' (so you cannot rely on port numbers to decide
accept or deny). Thi
On Thu, Apr 02, 2009 at 01:00:59PM +0200, Paolo Pisati wrote:
> Luigi Rizzo wrote:
> >
> >Ok then we may have a plan:
> >
> >you could do is implement REASS as an action (not as a microinstruction),
> >with the following behaviour:
> >
> >- if the packet is a complete one, the rule behaves as a "co
Luigi Rizzo wrote:
Ok then we may have a plan:
you could do is implement REASS as an action (not as a microinstruction),
with the following behaviour:
- if the packet is a complete one, the rule behaves as a "count"
(i.e. the firewall continues with the next rule);
- if the packet is a frag
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 > 1, and drop all fragments with offset 0 t
On Wednesday 18 March 2009, 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 > 1, and drop all fragments with offset 0 that are
> smal
On Wed, Mar 18, 2009 at 08:52:18AM -0700, Julian Elischer wrote:
> Luigi Rizzo wrote:
> >On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote:
> >...
> >>>Ok then we may have a plan:
> >>>
> >>>you could do is implement REASS as an action (not as a microinstruction),
> >>>with the follow
Luigi Rizzo wrote:
On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote:
...
Ok then we may have a plan:
you could do is implement REASS as an action (not as a microinstruction),
with the following behaviour:
- if the packet is a complete one, the rule behaves as a "count"
(i.e. th
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 > 1, and drop all fragments with offset 0 that are
smaller than a certain reasonable minimum length. What
would be
On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote:
...
> >Ok then we may have a plan:
> >
> >you could do is implement REASS as an action (not as a microinstruction),
> >with the following behaviour:
> >
> >- if the packet is a complete one, the rule behaves as a "count"
> > (i.e. th
Luigi Rizzo wrote:
On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote:
Luigi Rizzo wrote:
Thinking more about it, i believe that calling reass as an explicit
firewall action is useless, because if ip_reass fails due to lack of
all fragments you are back to square one:
what do
On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote:
> Luigi Rizzo wrote:
> >
> >Thinking more about it, i believe that calling reass as an explicit
> >firewall action is useless, because if ip_reass fails due to lack of
> >all fragments you are back to square one:
> > what do I do wit
Luigi Rizzo wrote:
Thinking more about it, i believe that calling reass as an explicit
firewall action is useless, because if ip_reass fails due to lack of
all fragments you are back to square one:
what do I do with this fragment ?
AFAIK ip_reass() never fails: if it's the last frag
On Tue, Mar 17, 2009 at 03:54:42PM +0100, Paolo Pisati wrote:
> Alex Dupre wrote:
> >Luigi Rizzo ha scritto:
> >>it is not related to dynamic rules, but to the fact that
> >>that the firewall is called before reassembling packets.
> >>The info (port numbers especially) is not available
> >>in the f
On Tuesday 17 March 2009, Paolo Pisati wrote:
> FYI i have a patch for ipfw nat that reassemble a packet before nat[*],
> but if the idea of an explicit packet reassembly action sounds good, i
> could move the code over there.
>
> [*] actually the patch is really simple, it's just a call to ip_reas
Alex Dupre wrote:
Luigi Rizzo ha scritto:
it is not related to dynamic rules, but to the fact that
that the firewall is called before reassembling packets.
The info (port numbers especially) is not available
in the fragments so the firewall cannot do anything.
The only solution would be to call
Luigi Rizzo ha scritto:
it is not related to dynamic rules, but to the fact that
that the firewall is called before reassembling packets.
The info (port numbers especially) is not available
in the fragments so the firewall cannot do anything.
The only solution would be to call the firewall
after
Sergey Matveychuk wrote:
Luigi Rizzo wrote:
On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote:
Dmitriy Demidov wrote:
Hi Luigi. Thank you for answer.
It is a big "surprise" for me that reassembling of IP datagrams is
done not *before* they go into firewall, but *after* :(
But
Luigi Rizzo wrote:
On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote:
Dmitriy Demidov wrote:
Hi Luigi. Thank you for answer.
It is a big "surprise" for me that reassembling of IP datagrams is done
not *before* they go into firewall, but *after* :(
But what's wrong with it? A fr
On Sunday 15 March 2009, Sergey Matveychuk wrote:
> Dmitriy Demidov wrote:
> > Hi Luigi. Thank you for answer.
> > It is a big "surprise" for me that reassembling of IP datagrams is done not
> > *before* they go into firewall, but *after* :(
>
> But what's wrong with it? A fragment got from net,
On Sun, Mar 15, 2009 at 12:38:37PM +0300, Sergey Matveychuk wrote:
> Dmitriy Demidov wrote:
> >Hi Luigi. Thank you for answer.
> >It is a big "surprise" for me that reassembling of IP datagrams is done
> >not *before* they go into firewall, but *after* :(
>
> But what's wrong with it? A fragment
Dmitriy Demidov wrote:
Hi Luigi. Thank you for answer.
It is a big "surprise" for me that reassembling of IP datagrams is done not
*before* they go into firewall, but *after* :(
But what's wrong with it? A fragment got from net, pass firewall and
store. After all fragments we got, OS reassemb
On Saturday 14 March 2009, Sergey Matveychuk wrote:
> What if you add:
>
> add allow ip from any to any frag
>
> instead the line above?
Hi Sergey.
Yes, it works this way. Unbound can do DNSSEC queues via this rule (and can not
without it).
Here is a example (both ipfw and unbound is just rest
Dmitriy Demidov wrote:
Unbound starts working only then I put in ipfw this set of rules to handle all
UDP packets outside from keep-state rules:
add allow udp from any to any
What if you add:
add allow ip from any to any frag
instead the line above?
add check-state
add deny icmp from any t
On Fri, Mar 13, 2009 at 10:46:48PM +0200, Dmitriy Demidov wrote:
> Hi list.
>
> I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via
> DLV (unbound gracefully allows it).
> My system is FreeBSD7-STABLE. I'm using ipfw.
>
> Original ipfw configuration:
> add check-state
> ad
Hi list.
I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via DLV
(unbound gracefully allows it).
My system is FreeBSD7-STABLE. I'm using ipfw.
Original ipfw configuration:
add check-state
add deny icmp from any to any frag
add allow icmp from any to me icmptypes 0,3,11
add
26 matches
Mail list logo