From: Tom <tom@then.fr>
To: neal.p.murphy@alum.wpi.edu
Cc: netfilter@vger.kernel.org
Subject: Re: NAT, DROP and walled-gardens (~= captive portal)
Date: Tue, 15 Jan 2013 21:18:40 +1000 [thread overview]
Message-ID: <50F53B10.7050305@then.fr> (raw)
In-Reply-To: <201301150131.52465.neal.p.murphy@alum.wpi.edu>
Re,
>> *Question*
>> Now, as you know we cannot DROP anymore in a NAT table. Therefore my
>> gardens are useless because I cannot drop at the end anymore. For the
>> moment I really don't see how I can easily have the same behaviour than
>> before. I can see a possible solution with more chains that would
>> involve the software to iptables -A to different chains which I'd like
>> to avoid :)
> If you cannot rely on default policy, then rely on active policy.
It is too bad you can't setup a default policy (-P) for your own chains.
It would have been too easy otherwise :)
> Pick an unused bit in packet MARKs; say it's bit 32 (mask 80000000). Have INPUT,
> OUTPUT and FORWARD chains in nat end with a rule to set the high-order bit in
> the packet's MARK; the assumption is that allowed packets will have caused a
> return before reaching the end of these chains. Then in INPUT, OUTPUT and
> FORWARD in filter, you first check that bit; if set, drop the packet.
I thought I could only mark in the mangle table and not in the nat
tables ? I will have to read the man again.
A solution, I am using at the moment is to DNAT to an IP I am
"blackholing" (ip route add blackhole). It's ugly and it works for now
but I am after a better and neater solution.
Thomas
next prev parent reply other threads:[~2013-01-15 11:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 6:31 NAT, DROP and walled-gardens (~= captive portal) Neal Murphy
2013-01-15 11:18 ` Tom [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-01-15 4:13 tom
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=50F53B10.7050305@then.fr \
--to=tom@then.fr \
--cc=neal.p.murphy@alum.wpi.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.