Re: Why can't we use DNAT in the INPUT Chain?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/19/2017 2:28 PM, /dev/rob0 wrote:
On Sat, Aug 19, 2017 at 01:36:20PM +0100, khawar shehzad wrote:
I have a simple question,
But the question seems to lack necessary understanding.
ok.

but I have a very compeling application which
requires this feature.

I want to do DNAT in the INPUT chain. I am doing filtration at the
PREROUTING chain (getting rid of some source IPs based on a vmap).

Those IPs which are accepted after the prerouting filter, I need
to DNAT them only. I don't want to use router to do it in the
FORWORD chain.
The thing you seem to be missing is the concept of tables.  Refer to
the iptables(8) manual discussion about tables.

Network address translation (NAT) only happens in the "nat" table;
this table has no "INPUT" nor "FORWARD" (note: spelling counts! ;) )
for your use.

Filtering is done in the "filter" table, which likewise, has no
"PREROUTING" chain.  To some extent you could filter in the "raw"
table, but there's not much benefit to that.

You did not describe your use case very well, but from the little
which did come across, perhaps you could drop certain source IP
addresses in raw/PREROUTING.  Then do DNAT in nat/PREROUTING as
normal.  These connections will be seen again in filter/FORWARD.

(If the list of blocked source addresses is large and/or dynamic,
consider ipset(8) and the -m set match.)

http://inai.de/images/nf-packet-flow.png might help you to see how
packets flow through the various tables and chains.

Try describing your problem and goal a bit better (what does "don't
want to use router to do it in the FORWORD chain" mean?  What's the
problem with normal DNAT?) then perhaps we can offer more and better
suggestions.
I want to the following:
1- Maintain a list of source IPs which will be granted access (I am using verdict maps, and added all source IPs there with an ACCEPT verdict) 2- The verdict map is used by the FILTER chain (which will reject the traffic unless there is an entry in the verdict map) 3- Once the packet is accepted by the FILTER chain (i.e. there is a mapping in the verdict map), I want to do DNAT (i.e. changing the destination address of the packet)

My interface is configure like this:
eth4 ==> 2001::21
eth4 ==> 2001::1:0:0:2

The example client (which will be allowed an access to the server) is 2001::20.

My solution is like the following, which is not working.

table ip6 natcap {
        map natcap_vmap {
                type ipv6_addr . ipv6_addr : verdict
                elements = { 2001::20 . 2001::1:0:0:2 : accept}
        }
        chain prerouting_filter {
                type filter hook prerouting priority -101; policy drop;
                ip6 saddr . ip6 daddr vmap @natcap_vmap
        }

        chain prerouting_nat {
                type nat hook prerouting priority -100;
                dnat to 2001::21
        }
        map natcap_map {
                type ipv6_addr : ipv6_addr
                elements = { 2001::20 : 2001::1:0:0:2 }
        }

        chain postrouting_nat {
                type nat hook postrouting priority 100; policy drop;
                snat to ip6 daddr map @natcap_map
        }
}


Note the have set the priority such that chains work in order. But still no luck.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux