NAT, DROP and walled-gardens (~= captive portal)

NAT, DROP and walled-gardens (~= captive portal)

[tom]

Hey guys,

*Problem*
I've just hit the deprecation of DROP in the NAT tables.
iptables v1.4.7:
The "nat" table is not intended for filtering, the use of DROP is 
therefore inhibited.

*Context*
- I have a Centos 6.3 acting as router and running iptables.
- It routes traffic in and out.
- It also has different 'walled-gardens' which restrict a source 
IP(s).
- An IP in a 'walled-garden' has for intance the following 
restrictions:
  * Access to a limited set of servers (in house or on the Net).
  * Access to DNS servers
  * Port 80 rewritten to a default server
  * Drop all the rest of the traffic
- I have different kind of gardens with different set of rules to 
restrict IPs (users). A garden must have a default policy set to drop.
- The IP (user) are added and removed from a garden by a software 
using iptables.

With our old Centos4 I was using the following which worked fine:
- Example of a walled-garden definition:
/sbin/iptables -t nat -N garden
/sbin/iptables -t nat -A garden -p udp -m udp --dport 53 -j DNAT --to 
1.1.1.1
/sbin/iptables -t nat -A garden -p tcp -m tcp -d 3.3.3.3 -j ACCEPT
/sbin/iptables -t nat -A garden -p tcp -m tcp --dport 80 -j DNAT --to 
80.80.80.80
/sbin/iptables -t nat -A garden -j DROP

- Definition of the chain where the software will put users in:
/sbin/iptables -t nat -N garden_users
/sbin/iptables -t nat -A PREROUTING -j garden_users

- Add or remove a user in a garden via software with :
/sbin/iptables -t nat -A garden_users -s IP.TO.GAR.DEN -j garden
/sbin/iptables -t nat -D garden_users -s IP.TO.GAR.DEN -j garden

*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 :)

I'd like to have your insights first to see if there is something 
obvious I cannot see or not fully understanding.

Any ideas are welcome.

Thomas

Re: NAT, DROP and walled-gardens (~= captive portal)

[Neal Murphy]

On Monday, January 14, 2013 11:13:39 PM tom@then.fr wrote:
> Hey guys,
> 
> *Problem*
> I've just hit the deprecation of DROP in the NAT tables.
> iptables v1.4.7:
> The "nat" table is not intended for filtering, the use of DROP is
> therefore inhibited.
> ...
> *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 :)

One solution:

If you cannot rely on default policy, then rely on active policy. 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.

N

Re: NAT, DROP and walled-gardens (~= captive portal)

[Tom]

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