Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1969

Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited)

Show all headers | View raw

Andrew Gideon a écrit :
> On Thu, 21 Feb 2013 09:46:30 +0100, Pascal Hambourg wrote:
> 
>> You know what SNAT rules you have in nat.POSTROUTING. So you know what
>> packets in filter.FORWARD will be SNATed or already have a valid source
>> address. You can create filtering rules which match the same packets as
>> the SNAT rules but with the ACCEPT target instead of SNAT.
> 
> I deliberately avoid this right now for a couple of reasons.
> 
> First, this means that any given expression that SNAT is occurring must be
> implemented twice.  Redundancy of this sort is never a good thing; it
> means that two different but effectively identical sets of rules need to
> be maintained.

Redundancy of this sort is common with NAT however. For example when you
do port forwarding (destination NAT), you need one DNAT rule in
nat.PREROUTING and one ACCEPT rule in filter.FORWARD for the final
destination. Why would it be different with source NAT ?

You can make it easier by keeping the two rules together in the script,
or using functions which create both rules based on the same parameters.
Or you can mark packets and apply multiple operations in different
tables and chains to packets with a given mark.

> Second, this presumes that the rules are perfect.  That is, if I err
> somehow in filter.FORWARD such that a packet that should be either blocked
> or SNATed is not, then the duplicated logic in nat.POSTROUTING will have
> the same error.

There is nothing specific in your case. Wrong rules always result in
packets being incorrectly processed... Deal with it, as all people who
write rulesets do. After writing or modifying a ruleset, you must test it.

> I'm thinking that the only solution that's really guaranteed to avoid
> leaking packets with bad source IPs is to have nat.POSTROUTING SNAT
> anything with a bad source IP.

That is not even true. Not all outgoing packets pass through
nat.POSTROUTING. The nat table chains see only (but not all) packets in
the state NEW. Packet is in any other state skip the nat table chains.
This the reason why filtering in this table is not reliable.

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Andrew Gideon <c182driver9@gideon.org> - 2013-02-19 00:00 +0000
  Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2013-02-21 09:46 +0100
    Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Andrew Gideon <c182driver9@gideon.org> - 2013-02-21 20:08 +0000
      Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Ken Sims <ng12207@kensims.#nospam#.net.invalid> - 2013-02-21 20:54 -0800
      Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2013-02-23 10:26 +0100
        Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Ken Sims <ng12207@kensims.#nospam#.net.invalid> - 2013-02-23 07:17 -0800

csiph-web