Diagnosing "Error: NAT is only supported for IPv4/IPv6"

Diagnosing "Error: NAT is only supported for IPv4/IPv6"

[Jeff Kletsky]

Objectives:

* Get DNAT working for IPv4 on "if_external"

* Get SNAT working for IPv4 on "if_external"

* Be able to easily draft, manage, and read rule execution "around" NAT
   (some rules before NAT, others after,
    with one "pair" for inbound and another pair for outbound packets)


TL;DR:

Ruleset parses and works as expected without NAT statements.

Adding simple NAT statements results in "meaningless" reference in error 
message:

     In file included from nftables.conf:114:5-45:
     ./blackhole_check_internal.nft:6:54-57: Error: NAT is only 
supported for IPv4/IPv6
     nal_allowed_net {
^^^^

That's a non-sequetor, nowhere near any NAT-related statement.

The NAT-related statements are in an "inet" table.

The NAT-related statements are all "protected" with "ip version 4" now,
and the problem still persists.

How do I locate the problem?




nftables.conf (excerpts):


       1 #!/usr/sbin/nft -f
       2
       3 flush ruleset
       4
       5 table inet global {
       6
       7     define if_external = eth1
       8     define if_internal = eth0

[...]

     101     #
     102
     103     include "./nat_rules_inbound_ipv4.nft"
     104     include "./nat_rules_outbound_ipv4.nft"
     105
     106     #
     107
     108     include "./postrouting_ext_int.nft"
     109     include "./postrouting_int_ext.nft"
     110
     111     #
     112
     113     include "./blackhole_check_external.nft"
     114     include "./blackhole_check_internal.nft"
     115
     116     #

[...]

     123     chain prerouting {
     124         type filter hook prerouting priority 0
     125         policy drop

[...]

     273     chain postrouting {
     274         type filter hook postrouting priority 0
     275         policy drop

[...]


Yes, I'm aware that I'm revealing the testing IPs and nets here

Yes, I've already run into what appears to be a 32-character limit on 
chain names and changed the names as a result
(No thanks to "Numerical result out of range" and "No such file or 
directory" error messages in finding *that* problem)

blackhole_check_internal.nft

       1 define if_internal_ip = { 10.10.10.131, 10.10.10.255 }
       2
       3 set if_internal_allowed_net {
       4     type ipv4_addr
       5     flags interval
       6     elements = { 10.10.10.0/24 }
       7 }
       8
       9
      10 chain blackhole_check_internal_pre {
      11
      12     ip saddr != @if_internal_allowed_net jump blackhole_src
      13
      14     ip daddr != $if_internal_ip jump blackhole_dst
      15
      16     return
      17 }
      18
      19
      20 chain blackhole_check_internal_post {
      21
      22     ip saddr != $if_internal_ip jump blackhole_src
      23
      24     ip daddr != @if_internal_allowed_net jump blackhole_dst
      25
      26     return
      27 }


The reference to

./blackhole_check_internal.nft:6:54-57

appears to be a complete non-sequetor, at least as far as NAT goes.
(The ruleset, without the NAT includes and jumps parses, compiles, and 
works as expected)



nat_rules_inbound_ipv4.nft:

       1 chain nat_rules_inbound_ipv4 {
       2
       3     iifname != $if_external return
       4
       5     ip version 4 tcp dport @forwarded_ports_wildside dnat $wildside
       6
       7     return

       8 }

nat_rules_outbound_ipv4.nft

       1 chain nat_rules_outbound_ipv4 {
       2
       3     oifname != $if_external return
       4
       5     ip version 4 snat $wildside
       6
       7     return
       8 }


$wildside is an IPv4 address literal in dotted-quad notation

@forwarded_ports_wildside is of "type inet_service" and is non-empty


Both the dnat and snat expressions, themselves, are restricted to IPv4, 
as a futile attempt to convince nft that it is only NAT-ing IPv4

In prerouting chain:

     iifname $if_external jump nat_rules_inbound_ipv4

In postrouting chain:

     oifname $if_external jump nat_rules_outbound_ipv4

(this approach allows me to have rules before and after the NAT in the 
prerouting and postrouting chains)


How do I go about deducing what the real problem here is?

Thanks,


Jeff

Re: Diagnosing "Error: NAT is only supported for IPv4/IPv6"

[Jeff Kletsky]

Digging into the cause (and, for now ignoring the unhelpful error 
message), this appears to be a bug in nft

No matter what the documentation says, it appears that NAT statements 
can't be in an "inet" table

Parses and loads with "table ip"
================================

#!/usr/sbin/nft -f

flush ruleset

table ip global {

     chain nat_in {
         type nat hook prerouting priority -100
     continue
     }

     chain nat_out {
         type nat hook postrouting priority -100
     continue
     }

}


Fails with "table inet"
=======================

#!/usr/sbin/nft -f

flush ruleset

table inet global {

     chain nat_in {
         type nat hook prerouting priority -100
     continue
     }

     chain nat_out {
         type nat hook postrouting priority -100
     continue
     }

}


The error messages here are different, but equally useless

$ sudo nft -f nftables.conf
nftables.conf:3:1-14: Error: Could not process rule: No such file or 
directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or 
directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or 
directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or 
directory
flush ruleset
^^^^^^^^^^^^^^


On 8/21/17 2:42 PM, Jeff Kletsky wrote:

> Objectives:
>
> * Get DNAT working for IPv4 on "if_external"
>
> * Get SNAT working for IPv4 on "if_external"
>
> * Be able to easily draft, manage, and read rule execution "around" NAT
>   (some rules before NAT, others after,
>    with one "pair" for inbound and another pair for outbound packets)
>
>
> TL;DR:
>
> Ruleset parses and works as expected without NAT statements.
>
> Adding simple NAT statements results in "meaningless" reference in 
> error message:
>
>     In file included from nftables.conf:114:5-45:
>     ./blackhole_check_internal.nft:6:54-57: Error: NAT is only 
> supported for IPv4/IPv6
>     nal_allowed_net {
> ^^^^
>
> That's a non-sequetor, nowhere near any NAT-related statement.
>
> The NAT-related statements are in an "inet" table.
>
> The NAT-related statements are all "protected" with "ip version 4" now,
> and the problem still persists.
>
> How do I locate the problem?

Re: Diagnosing "Error: NAT is only supported for IPv4/IPv6"

[Pablo Neira Ayuso]

On Tue, Aug 22, 2017 at 09:55:10AM -0700, Jeff Kletsky wrote:
> Digging into the cause (and, for now ignoring the unhelpful error message),
> this appears to be a bug in nft
> 
> No matter what the documentation says, it appears that NAT statements can't
> be in an "inet" table
> 
> Parses and loads with "table ip"
> ================================
> 
> #!/usr/sbin/nft -f
> 
> flush ruleset
> 
> table ip global {
> 
>     chain nat_in {
>         type nat hook prerouting priority -100
>     continue
>     }
> 
>     chain nat_out {
>         type nat hook postrouting priority -100
>     continue
>     }
> 
> }
> 
> 
> Fails with "table inet"
> =======================
> 
> #!/usr/sbin/nft -f
> 
> flush ruleset
> 
> table inet global {
> 
>     chain nat_in {
>         type nat hook prerouting priority -100
>     continue
>     }
> 
>     chain nat_out {
>         type nat hook postrouting priority -100
>     continue
>     }
> 
> }
> 
> 
> The error messages here are different, but equally useless
> 
> $ sudo nft -f nftables.conf
> nftables.conf:3:1-14: Error: Could not process rule: No such file or
> directory
> flush ruleset
> ^^^^^^^^^^^^^^
> nftables.conf:3:1-14: Error: Could not process rule: No such file or
> directory
> flush ruleset
> ^^^^^^^^^^^^^^
> nftables.conf:3:1-14: Error: Could not process rule: No such file or
> directory
> flush ruleset
> ^^^^^^^^^^^^^^
> nftables.conf:3:1-14: Error: Could not process rule: No such file or
> directory
> flush ruleset
> ^^^^^^^^^^^^^^

This is working since:

commit 509671dfa03365bba727b8be5e522b737da93a6f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jun 15 14:35:33 2017 +0200

    src: error reporting for nested ruleset representation

Would you give a try to nft.git snapshot to confirm this?

This will be included in the next release.

Re: Diagnosing "Error: NAT is only supported for IPv4/IPv6"

[Jeff Kletsky]

No updates seen from git (my build was previously done on 2017-08-19),
but did an uninstall, re-configure, make, reinstall to confirm.


I do see in output from 'git log'

commit 509671dfa03365bba727b8be5e522b737da93a6f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jun 15 14:35:33 2017 +0200


I have confirmed that nft is not available after the uninstall


Same behavior as before

Jeff


       1 #!/usr/sbin/nft -f
       2
       3 flush ruleset
       4
       5 table inet global {
       6
       7     chain nat_in {
       8         type nat hook prerouting priority -100
       9     continue
      10     }
      11
      12     chain nat_out {
      13         type nat hook postrouting priority -100
      14     continue
      15     }
      16
      17 }

$ sudo nft -f tmp
tmp:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^
tmp:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^
tmp:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^
tmp:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^

~/build/nftables$ git log -1
commit d74eed8c9649e9278b69f2cd0fd92f71e3e19cfb (HEAD -> master, tag: 
2017-08-19, origin/master, origin/HEAD)
Author: Varsha Rao <rvarsha016@gmail.com>
Date:   Wed Aug 16 19:48:17 2017 +0530

~/build/libmnl$ git log -1
commit fbe0f33b45abd585eb9f52cb56d751a750667dc6 (HEAD -> master, tag: 
2017-08-19, origin/master, origin/HEAD)
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Aug 3 12:52:34 2016 +0200

~/build/libnftnl$ git log -1
commit d58998312375de0865091cfc5d00ddd271d9a44c (HEAD -> master, tag: 
2017-08-19)
Author: Eric Leblond <eric@regit.org>
Date:   Thu Jul 6 13:58:27 2017 +0100





On 8/22/17 10:33 AM, Pablo Neira Ayuso wrote:
> On Tue, Aug 22, 2017 at 09:55:10AM -0700, Jeff Kletsky wrote:
>> Digging into the cause (and, for now ignoring the unhelpful error message),
>> this appears to be a bug in nft
>>
>> No matter what the documentation says, it appears that NAT statements can't
>> be in an "inet" table
>>
>> Parses and loads with "table ip"
>> ================================
>>
>> #!/usr/sbin/nft -f
>>
>> flush ruleset
>>
>> table ip global {
>>
>>      chain nat_in {
>>          type nat hook prerouting priority -100
>>      continue
>>      }
>>
>>      chain nat_out {
>>          type nat hook postrouting priority -100
>>      continue
>>      }
>>
>> }
>>
>>
>> Fails with "table inet"
>> =======================
>>
>> #!/usr/sbin/nft -f
>>
>> flush ruleset
>>
>> table inet global {
>>
>>      chain nat_in {
>>          type nat hook prerouting priority -100
>>      continue
>>      }
>>
>>      chain nat_out {
>>          type nat hook postrouting priority -100
>>      continue
>>      }
>>
>> }
>>
>>
>> The error messages here are different, but equally useless
>>
>> $ sudo nft -f nftables.conf
>> nftables.conf:3:1-14: Error: Could not process rule: No such file or
>> directory
>> flush ruleset
>> ^^^^^^^^^^^^^^
>> nftables.conf:3:1-14: Error: Could not process rule: No such file or
>> directory
>> flush ruleset
>> ^^^^^^^^^^^^^^
>> nftables.conf:3:1-14: Error: Could not process rule: No such file or
>> directory
>> flush ruleset
>> ^^^^^^^^^^^^^^
>> nftables.conf:3:1-14: Error: Could not process rule: No such file or
>> directory
>> flush ruleset
>> ^^^^^^^^^^^^^^
> This is working since:
>
> commit 509671dfa03365bba727b8be5e522b737da93a6f
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date:   Thu Jun 15 14:35:33 2017 +0200
>
>      src: error reporting for nested ruleset representation
>
> Would you give a try to nft.git snapshot to confirm this?
>
> This will be included in the next release.
>