Re: packets dropped when using MASQ and QUEUE

Re: packets dropped when using MASQ and QUEUE

[Mattias Rönnblom]

"sufcrusher" <sufcrusher@zonnet.nl> writes:

> I've had the exact same problem. I did a google search on this and found out
> pretty quickly that this is how it's supposed to be. For a really technical
> explanation you might want to do a google search yourself, but it comes down
> to the fact that the userspace program can only completely ACCEPT or
> DENY/REJECT a packet. It can *not* let the packet continue traversing the
> chains/tables.

Cannot continue traversing that particular chain (FORWARD, in my case),
or any chain? My MASQ rules are on the POSTROUTING chain.

And if it's a design flaw i QUEUE, how come it works for some of
the packets, but not all?

Kind regards,
        Mattias

Re: packets dropped when using MASQ and QUEUE

[Jannes Faber]

I experimented again with the scripts I wrote to do this, but it really
doesn't work. If you NF_ACCEPT a packet without altering it, there is no
problem and the masquerading works ok. But as soon as you try to NF_ACCEPT
an altered packet it gets lost.

On the other hand when you send a packet to the box itself (so there is no
NAT), it works perfectly: including the altered packets.

I tried to refind the articles I read about it a few months back, but I
couldn't find them again.

I think what you need is a new target that can alter the packets in
kernel-space for you. Like the TOS target can alter the TOS bits, you need
something like a REPLACE target or maybe even a REGEXP target. There already
exists a string match extension (in patch-o-matic I think) that lets you
search through the packet contents, but as far as I know not something to
alter the packets.

Jannes Faber

From: "Mattias Rönnblom" <hofors@lysator.liu.se>


> "sufcrusher" <sufcrusher@zonnet.nl> writes:
>
> > I've had the exact same problem. I did a google search on this and found
out
> > pretty quickly that this is how it's supposed to be. For a really
technical
> > explanation you might want to do a google search yourself, but it comes
down
> > to the fact that the userspace program can only completely ACCEPT or
> > DENY/REJECT a packet. It can *not* let the packet continue traversing
the
> > chains/tables.
>
> Cannot continue traversing that particular chain (FORWARD, in my case),
> or any chain? My MASQ rules are on the POSTROUTING chain.
>
> And if it's a design flaw i QUEUE, how come it works for some of
> the packets, but not all?
>
> Kind regards,
>         Mattias
>
>

Re: packets dropped when using MASQ and QUEUE

[Mattias Rönnblom]

"Jannes Faber" <jafaber@zonnet.nl> writes:

> I experimented again with the scripts I wrote to do this, but it really
> doesn't work. If you NF_ACCEPT a packet without altering it, there is no
> problem and the masquerading works ok. But as soon as you try to NF_ACCEPT
> an altered packet it gets lost.
>
> On the other hand when you send a packet to the box itself (so there is no
> NAT), it works perfectly: including the altered packets.
> 
> I tried to refind the articles I read about it a few months back, but I
> couldn't find them again.
> 
> I think what you need is a new target that can alter the packets in
> kernel-space for you. Like the TOS target can alter the TOS bits, you need
> something like a REPLACE target or maybe even a REGEXP target. There already
> exists a string match extension (in patch-o-matic I think) that lets you
> search through the packet contents, but as far as I know not something to
> alter the packets.
> 

I'm in no need of any new targets. I don't want to alter any packets,
but rather only delay and occansionally drop packets. QUEUE would
work fine, if I only could get it to really work.

Kind regards,
        Mattias