netfilter buglog - Jan 2017 - [Bug 1115] New: Not all packets leaving the system get masqueraded

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

            Bug ID: 1115
           Summary: Not all packets leaving the system get masqueraded
           Product: iptables
           Version: 1.4.x
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: iptables
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: dennisml at conversis.de

I'm seeing a strange phenomenon where some packets apparently bypass the
MASQUERADE rule identified by iptables.
The rule looks like this:
-A POSTROUTING -s 10.23.0.0/16 -o eth1 -j MASQUERADE

Doing a "tcpdump -nn -i eth1 src net 10.23.0.0/16" shows several
packets per
second that leave the system with a source ip of 10.23.0.x. What these packets
all have in common is that they either have the RST or FIN flag set.
Since none of these connections show up in the conntrack table after I see
these packets I'm wondering if this is some kind of race condition where the
connection gets dropped from the table when this packet is encountered and when
it is sent out the interface the information required to translate the source
address is no longer available and the packet gets sent out as is.

I'm seeing all of this on a CentOS 7 system.

-- 
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/20170126/4623e01a/attachment.html>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pablo at netfilter.org
             Status|NEW                         |ASSIGNED

--- Comment #1 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Probably some packets are considered invalid by conntrack.

You can check if this is the case by enabling conntrack tcp logging:

# modprobe xt_LOG
# echo 6 > /proc/sys/net/netfilter/nf_conntrack_log_invalid

-- 
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/20170126/70d652da/attachment.html>