netfilter buglog - Dec 2016 - [Bug 1105] New: masquerade fully broken when no prerouting chain is created

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

            Bug ID: 1105
           Summary: masquerade fully broken when no prerouting chain is
                    created
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: other
            Status: NEW
          Severity: major
          Priority: P5
         Component: kernel
          Assignee: pablo at netfilter.org
          Reporter: s1410239008 at students.fh-hagenberg.at

When no prerouting hook is created, the packets will be able to pass though the
machine outside but the answers will not be redirected to the original source.

So if I ping from a lxc container to an IP like 8.8.8.8 the packet will pass
with the source IP of the host but the answers are not forwarded back.

Creating an empty prerouting chain with its hook solved the issue.

My NAT rules are:
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }
  chain postrouting {
    type nat hook postrouting priority 0;
    oifname eth0 masquerade
  }
}

Kernel: 4.8.13-1-ARCH
Version: nftables 1:0.6-3
Distribution: ArchLinux

-- 
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/20161224/cff57c0a/attachment.html>

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

Maxime de Roucy <maxime.deroucy at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxime.deroucy at gmail.com

--- Comment #1 from Maxime de Roucy <maxime.deroucy at gmail.com> ---
I think it's explicitly mentioned in the wiki :

https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Masquerading
> Note that:
>    masquerade only makes sense from postrouting chain of NAT type.
>    **you still have to add the prerouting nat chain, since this translate
traffic in the reply direction.**
I don't know if it should be classified has a bug… though I am not a nftable
dev.

-- 
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/20170815/77fab7e1/attachment.html>

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

--- Comment #2 from Fabian Franz <s1410239008 at students.fh-hagenberg.at>
---
First of all: If you look at the creation date, this ticket is older than the
change of the wiki entry.

Second:
An empty chain is something that should not exist in nftables in my opinion.
Doing NAT in only one direction, which breaks all TCP connections, is
definitely incorrect behaviour in any setup. So it has to NAT in both
directions or in none of them.

-- 
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/20170818/bb201356/attachment.html>

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

Jos� Pekkarinen <koalinux at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |koalinux at gmail.com

--- Comment #3 from Jos� Pekkarinen <koalinux at gmail.com> ---
Created attachment 545
  --> https://bugzilla.netfilter.org/attachment.cgi?id=545&action=edit
rule set.

I believe I hit this problem on a 4.17.11, is this bug still valid? Some output
attached for perusal.

-- 
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/20180810/12f836f7/attachment.html>

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

--- Comment #4 from Fabian Franz <s1410239008 at students.fh-hagenberg.at>
---
@Jose:

try to remove that chain...

---
        chain prerouting {
                type nat hook prerouting priority 0; policy accept;
        }
---

...and see what happens. If you get packet loss, then that's what this
ticket
is about.

-- 
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/20180810/2ec60ba6/attachment.html>

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

--- Comment #5 from Jos� Pekkarinen <koalinux at gmail.com> ---
Yes, I misread that, sorry, my trouble was a different one so I eventually just
made noise to yours. Apparently the bond interfaces aren't the out
interfaces
as such, I dropped the oifname from my postrouting chain, letting the system
choose the out oifname for me and is working now.

Jos�.

-- 
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/20180810/2094b454/attachment.html>

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

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Florian Westphal <fw at strlen.de> ---
(In reply to Fabian Franz from comment #0)
> When no prerouting hook is created, the packets will be able to pass though
> the machine outside but the answers will not be redirected to the original
> source.
> 
> So if I ping from a lxc container to an IP like 8.8.8.8 the packet will
pass
> with the source IP of the host but the answers are not forwarded back.
> 
> Creating an empty prerouting chain with its hook solved the issue.
This is fixed with kernel 4.18 via
commit 9971a514ed2697e542f3984a6162eac54bb1da98
netfilter: nf_nat: add nat type hooks to nat core

-- 
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/20190315/a9492d92/attachment.html>