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

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

[khawar shehzad]

Hi,

I have a simple question, 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.

Any help will be much appreciated.

Cheers,

Khawar

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

[/dev/rob0]

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.

> 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.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

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

[khawar shehzad]

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

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

[Pascal Hambourg]

Le 19/08/2017 à 16:16, khawar shehzad a écrit :
> 
> 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)

DNAT makes sense only before the decision routing (so that the routing 
can be adapted to the new destination). So iptables allowed it only in 
the PREROUTING and OUTPUT chains.

> 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
>          }
(...)

What is this syntax ? This is not iptables.

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

[Duncan Roe]

On Sat, Aug 19, 2017 at 07:07:41PM +0200, Pascal Hambourg wrote:
> Le 19/08/2017 à 16:16, khawar shehzad a écrit :
[SNIP]
> > 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
> >          }
> (...)
>
> What is this syntax ? This is not iptables.
It's nftables, the reason I joined this list (to get my head around nftables ;)

Cheers ... Duncan.

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

[khawar shehzad]

So, the question is: Can we FILTER packets (in my case accepting packets 
which have a specific source IPv6 Addresses) before doing NAT in the 
same box/machine/server (using iptables or nftables)?


On 8/20/2017 3:15 AM, Duncan Roe wrote:
> On Sat, Aug 19, 2017 at 07:07:41PM +0200, Pascal Hambourg wrote:
>> Le 19/08/2017 à 16:16, khawar shehzad a écrit :
> [SNIP]
>>> 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
>>>           }
>> (...)
>>
>> What is this syntax ? This is not iptables.
> It's nftables, the reason I joined this list (to get my head around nftables ;)
>
> Cheers ... Duncan.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pascal Hambourg]

Le 20/08/2017 à 09:31, khawar shehzad a écrit :
> So, the question is: Can we FILTER packets (in my case accepting packets 
> which have a specific source IPv6 Addresses) before doing NAT in the 
> same box/machine/server (using iptables or nftables)?

Sure. With iptables you can do it in the raw or mangle PREROUTING 
chains, even though they are not primarily intended for filtering.

However, when the host is a router, filtering in PREROUTING is not the 
same as filtering in INPUT : PREROUTING sees all packets entering the 
host, while INPUT sees only packets directed at the host itself (after 
DNAT).

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

[Pascal Hambourg]

Le 19/08/2017 à 15:28, /dev/rob0 a écrit :
> 
> Network address translation (NAT) only happens in the "nat" table;
> this table has no "INPUT" nor "FORWARD" (note: spelling counts! ;) )
> for your use.

The nat table has had an INPUT chain for quite some time now. It allows 
to do SNAT, but not DNAT.

> 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.

Among the benefits of early filtering in the raw table are :
- avoid the unnecessary conntrack processing and decision routing when 
the packet is to be dropped ;
- process packets as they were received, before any transformation in 
the mangle and nat tables.

The former benefit can be useful to save CPU cycles on busy machines.