Re: packets dropped when using MASQ and QUEUE

["Jannes Faber" <jafaber@zonnet.nl>]

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
>
>