Re: Nat OUTPUT chain

[Patrick Schaaf <bof@bof.de>]

Hi all,

> Why do you DROP in the nat table instead of the filter table ?

Note that there are situations where this is advisable, and other
approaches result in more complex rulesets.

Imagine a situation where you want to REDIRECT certain incoming
connections, e.g.  everything to --dport 80, with the local service
running on port 3128. However, you DON'T want to have those redirected
clients access 3128 DIRECTLY. Using REDIRECT, both the direct and
redirected connections arrive in the filter table's INPUT chain,
and cannot be easily distinguished there, because the filter table
sees the rewritten destination IP and port.

My first solution involved the mangle table, tagging the different
incoming packets with an fwmark, and using that fwmark in both the
NAT and filter tables.

My current solution does the desired REDIRECTs in the NAT table,
and DROPs everything unwanted right there; the filter table just
permits the redirected port 3128 traffic. So that's where I found
good use for DROP in the NAT table.

An alternative, not doable with stock iptables (there's something
in p-o-m, I think), would be a filter table target which is capable
of matching the ORIGINAL_DESTINATION of the REDIRECTed connections.

best regards
  Patrick