netfilter buglog - Feb 2017 - [Bug 1117] New: Table ipv4-nat prerouting dnat doesn't accept dest IP:PORT

https://bugzilla.netfilter.org/show_bug.cgi?id=1117

            Bug ID: 1117
           Summary: Table ipv4-nat prerouting dnat doesn't accept dest
                    IP:PORT
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: jan at purepeople.be

Gents, in linux 4.9.6 there's something fish when applying an nftables rule
in
a netns.

# on the Host

-------
ovs-vsctl add-port bkpln pub-aaaa tag=200 -- set Interface pub-aaaa
type=internal
ip link add vx-aaa type vxlan id 123 group 239.0.1.123 dstport 4789 dev enp3s0
# enp3s0 has mtu 1550
ip netns add vr-aaaa
ip l set pub-aaa netns vr-aaaa
ip l set vx-aaaa netns vr-aaaa

-------
# enter the NS, easier
ip netns exec vr-aaaa bash
ip l set lo up
ip addr add 192.168.16.243/24 dev pub-aaaa
ip l set pub-aaaa up
ip addr add 192.168.123.1/24  dev vx-aaaa
ip l set vx-aaaa up
ip r add default via 192.168.16.254
-------
So far, so good

--------
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
14: pub-aaaa: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
noqueue
state UNKNOWN group default qlen 1000
    link/ether 86:ac:d7:df:eb:40 brd ff:ff:ff:ff:ff:ff
    inet 192.168.16.243/24 scope global pub-aaaa
       valid_lft forever preferred_lft forever
    inet6 fe80::84ac:d7ff:fedf:eb40/64 scope link 
       valid_lft forever preferred_lft forever
18: vx-aaaa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state
UNKNOWN group default qlen 1000
    link/ether 6e:5b:b8:06:12:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.123.1/24 scope global vx-aaaa
       valid_lft forever preferred_lft forever
    inet6 fe80::6c5b:b8ff:fe06:128d/64 scope link 
       valid_lft forever preferred_lft forever

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=41 time=74.2 ms
^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.264/74.264/74.264/0.000 ms

-----------------

Good

Now do some nftables stuff...

------------------
cat nftables.aaaa
#!/usr/bin/nft -f
flush ruleset 
table ip nat {
    chain prerouting {
        type nat hook prerouting priority -150; policy accept;
    }
    chain postrouting {
        type nat hook postrouting priority -150; policy accept;
        oifname "pub-aaaa" masquerade
    }
}
table inet filter {
    chain input {
        type filter hook input priority 0; policy accept;
    }
    chain forward {
        type filter hook forward priority 0; policy accept;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}
-----------------

So far so good...

-----------------
# nft list table ip nat
table ip nat {
    chain prerouting {
        type nat hook prerouting priority -150; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority -150; policy accept;
        oifname "pub-aaaa" masquerade
    }
}
---------------

Now add a port forward:


------------------
# nft add rule ip nat prerouting iif pub-aaaa tcp dport 80 dnat
192.168.123.20:80
# no error
# nft list table ip nat -nn -a
table ip nat {
    chain prerouting {
        type nat hook prerouting priority -150; policy accept;
        iif "pub-aaaa" tcp dport 80 dnat to :80 # handle 4
    }

    chain postrouting {
        type nat hook postrouting priority -150; policy accept;
        oifname "pub_aaaa" masquerade # handle 3
    }
}
--------

Here , in handled #4, the destination ip isn't added in the ruleset, but the
destination port is.
But:

--------
# nft add rule ip nat prerouting iif pub-aaaa tcp dport 8080 dnat
192.168.123.20
# no error
# nft list table ip nat -nn -a
table ip nat {
    chain prerouting {
        type nat hook prerouting priority -150; policy accept;
        iif "pub-aaaa" tcp dport 80 dnat to :80 # handle 4
        iif "pub-aaaa" tcp dport 8080 dnat to 192.168.123.20 # handle
5
    }

    chain postrouting {
        type nat hook postrouting priority -150; policy accept;
        oifname "pub_aaaa" masquerade # handle 3
    }
}
---------

Handle 5 has a dest ip, when no destport is specfied

Thought you might want to know, unless I do something gravely wrong ...

NOTE all these commands after `ip netns exec vr-aaaa bash` are IN the namespace

NOTE 2 issuing command `nft add rule ip nat prerouting iif pub-aaaa tcp dport
80 dnat 192.168.123.20:80` when NOT in a namespace updates the table correctly

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170203/5fd0a429/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1117

--- Comment #1 from Jan <jan at purepeople.be> ---
with kernel 4.4 (std ubuntu) and nftables 0.5
---------------
root at ctrl-ma-g8-1:~# nft add rule ip nat prerouting iif public tcp dport 9999
dnat 10.108.2.123:999
root at ctrl-ma-g8-1:~# nft list ruleset
table ip nat {
    chain prerouting {
        type nat hook prerouting priority -150; policy accept;
        iif public tcp dport 9999 dnat 10.108.2.123:999 
    }

    chain postrouting {
        type nat hook postrouting priority -150; policy accept;
        oif public ip saddr 10.108.2.0/24 masquerade 
        ip saddr 172.17.0.0/16 masquerade 
    }
}
----------------

things work....
IIRC on 4.8.11, things work too

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170203/f22829fc/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1117

--- Comment #2 from Jan <jan at purepeople.be> ---
> 
> NOTE 2 issuing command `nft add rule ip nat prerouting iif pub-aaaa tcp
> dport 80 dnat 192.168.123.20:80` when NOT in a namespace updates the table
> correctly
Corretion on NOTE2 :
Not correct :-) I think this is a regression since kernel 4.8, as on 4.9.6 even
when not in a namesapce, we get the same behavior

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170203/144dd3aa/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1117

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de
           Assignee|pablo at netfilter.org         |fw at strlen.de
             Status|NEW                         |ASSIGNED

--- Comment #3 from Florian Westphal <fw at strlen.de> ---
Got broken by commit 5ab0e10fc6e2c22363ad4428f9aaf8965ee71d51
("src: support for RFC2732 IPv6 address format with brackets") in
nftables
0.7

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170203/6e9c1931/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1117

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |pablo at netfilter.org

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Fixed by 4ae0b6dc90d16b4d93a4e8b6703f23dcf2467b85

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170307/c03c06d3/attachment.html>