From: Mart Frauenlob <mart.frauenlob@chello.at>
To: netfilter@vger.kernel.org
Subject: Re: transparent proxy
Date: Sat, 13 Mar 2010 22:58:58 +0100 [thread overview]
Message-ID: <4B9C0AA2.1090100@chello.at> (raw)
In-Reply-To: <20100313164108.GB10986@minipax>
On 13.03.2010 17:41, rob0@gmx.co.uk wrote:
> On Sat, Mar 13, 2010 at 01:08:45PM +0100, Mart Frauenlob wrote:
>> On 13.03.2010 11:05, netfilter-owner@vger.kernel.org wrote:
>
> NB, your MUA is changing the attribution to the envelope sender.
> Please don't blame the list owner for what I said! :) In a list
> reply, the attribution should be the header From: address, not the
> SMTP envelope sender address.
>
hrm, yes I see that for a while. I use Mozilla Thunderbird on windowz
(stuck to it here). And it's the only Mailing list where I encounter
this problem. And it does not occur for all mails. I have no idea why.
>>> On Sat, Mar 13, 2010 at 09:21:23AM +0100, Mart Frauenlob wrote:
>>>> Amos Jeffries:
>>>>> Please read the Squid FAQ examples of how to configure policy
>>>>> routing ...
>>>>>
>>>>> Router:
>>>>> http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
>>>>>
>>>>> Squid box:
>>>>> http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
>>>>
>>>> I'd like to ask, if in the above examples, the ACCEPT
>>>> rules need to be placed in the mangle table?
>>>> Is there a specific reason, couldn't it be done in the
>>>> filter table?
>>>> As that would be the intended/preferred use for filtering?
>>>> If so, don't the examples teach people 'bad manners'?
>>>
>>> I think Mart is misunderstanding the effect of ACCEPT in mangle.
>>> It does not override nor bypass the filter table. It merely
>>> means, "we are done mangling this packet."
>>
>> ACCEPT in mangle differs from ACCEPT in filter?
>
> Strictly speaking, no, ACCEPT is ACCEPT. Look at no more rules,
> disregard the chain's policy, pass Go, collect $200.
>
>> Where is that documented?
>> So you have to ACCEPT it twice? In mangle and in filter table?
>
> And raw, and nat ... the packet hits all relevant chains/tables. Any
> of these could change a packet's fate. However, IIUC support for the
> DROP target in nat and mangle has been removed.
>
I see. Well thank you! 'Mart' really had some misunderstanding about the
ACCEPT effect.
Guess I've always thought about it as the 'opposite' of DROP.
The man page isn't very clear there.
'ACCEPT means to let the packet through.'
would need at least a 'the table' at the end of the sentence.
>>> The MARK target is one of those sneaky non-terminating targets.
>>> A mark is applied, and the packet continues in that particular
>>> chain. Further -j MARK rules could be applied. The ACCEPT rule
>>> prevents this.
>>
>> Don't we use the RETURN target for that? But yes, that implies a
>> problem, if you RETURN from a user-defined chain.
>
> RETURN in a built-in means "go to the policy." In a user chain it
> means "go to the next rule in the calling chain". As you point out,
> there could be issues with that as the example. ACCEPT works. The
> only minor nitpick I can think of is that the example used -A,
> whereas -I would have covered more cases of crazy mangle rulesets.
>
> But, -I would fall into the "bad manners" category you were asking
> about originally. :) If someone has crazy mangle rules, let's hope
> they understand those rules, because if they don't, they'll have
> other problems beyond getting their squid working. :)
Best regards
Mart
next prev parent reply other threads:[~2010-03-13 21:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-09 23:44 transparent proxy Marco Schuth
2010-03-10 0:23 ` Amos Jeffries
2010-03-13 8:21 ` Mart Frauenlob
2010-03-13 10:05 ` /dev/rob0
2010-03-13 12:08 ` Mart Frauenlob
2010-03-13 12:11 ` Mart Frauenlob
2010-03-13 16:41 ` /dev/rob0
2010-03-13 21:58 ` Mart Frauenlob [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-03-17 12:33 Fredrik Emil Jensen
2004-03-17 14:21 ` David Cannings
2004-03-15 9:19 Fredrik Emil Jensen
2004-03-16 1:57 ` Alexander Samad
2004-03-16 8:44 ` Antony Stone
2004-02-27 19:19 Guillermo Chui Lau
2004-02-27 8:48 Tomasz Macioszek
2004-02-27 9:18 ` Jeroen Vriesman
2004-02-27 9:27 ` Antony Stone
2004-02-27 10:25 ` Jeroen Vriesman
2004-02-27 11:50 ` John A. Sullivan III
2004-02-27 17:00 ` Daniel F. Chief Security Engineer -
2003-09-10 21:19 Transparent Proxy Kilson Arruda
2002-11-25 13:04 Cyril COUPEL
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B9C0AA2.1090100@chello.at \
--to=mart.frauenlob@chello.at \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).