intermittent nat issue

intermittent nat issue

[Mark Coetser]

Hi All

kernel 3.16.0-4-686-pae
iptables 1.4.21-2+b1

I have a few different firewalls that are exhibiting the same issue

basic rule iptables -t nat -I POSTROUTING -o $external_iface -j MASQUERADE

when running tcpdump on $external_iface I am seeing SOME packets from 
the private_network not being masqueraded/natted.

-- 
Thank you,

Mark Adrian Coetser
mark@pkfnet.co.za

"Help save the world!"              -- Larry Wall in README

RE: intermittent nat issue

[Llorente Santos Jesus]

Hi Mark,

Did you flush the conntrack? Perhaps what you are seeing are some already established connections prior to setting the rule in iptables?
Try with "conntrack -D" to remove the connections.

Best,
Jesus

-----Original Message-----
From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Mark Coetser
Sent: 20 January 2017 08:25
To: netfilter@vger.kernel.org
Subject: intermittent nat issue

Hi All

kernel 3.16.0-4-686-pae
iptables 1.4.21-2+b1

I have a few different firewalls that are exhibiting the same issue

basic rule iptables -t nat -I POSTROUTING -o $external_iface -j MASQUERADE

when running tcpdump on $external_iface I am seeing SOME packets from the private_network not being masqueraded/natted.

--
Thank you,

Mark Adrian Coetser
mark@pkfnet.co.za

"Help save the world!"              -- Larry Wall in README

--
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: intermittent nat issue

[Mark Coetser]

Hi Llorente

I did run conntrack -F to check that but still had the unnatted packets 
traversing the interface.

-- 
Thank you,

Mark Adrian Coetser
mark@pkfnet.co.za

"The New York Times is read by the people who run the country.  The
Washington Post is read by the people who think they run the country. The
National Enquirer is read by the people who think Elvis is alive and running
the country ..."
		-- Robert J Woodhead


On 20/01/2017 09:21, Llorente Santos Jesus wrote:
> Hi Mark,
>
> Did you flush the conntrack? Perhaps what you are seeing are some already established connections prior to setting the rule in iptables?
> Try with "conntrack -D" to remove the connections.
>
> Best,
> Jesus
>
> -----Original Message-----
> From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Mark Coetser
> Sent: 20 January 2017 08:25
> To: netfilter@vger.kernel.org
> Subject: intermittent nat issue
>
> Hi All
>
> kernel 3.16.0-4-686-pae
> iptables 1.4.21-2+b1
>
> I have a few different firewalls that are exhibiting the same issue
>
> basic rule iptables -t nat -I POSTROUTING -o $external_iface -j MASQUERADE
>
> when running tcpdump on $external_iface I am seeing SOME packets from the private_network not being masqueraded/natted.
>
> --
> Thank you,
>
> Mark Adrian Coetser
> mark@pkfnet.co.za
>
> "Help save the world!"              -- Larry Wall in README
>
> --
> 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
> ���{.n�+�������+%�����ݶ\x17��w��{.n�+���z��׫�)���w*\x1fjg���\x1e�����ݢj��\a��G������\f���j:+v���w�j�m�����\x1e��\x1e�w�����f���h������٥
>

Re: intermittent nat issue

[Dennis Jacobfeuerborn]

On 20.01.2017 10:47, Mark Coetser wrote:
> Hi Llorente
> 
> I did run conntrack -F to check that but still had the unnatted packets
> traversing the interface.
> 

Hi, I'm seeing this as well on our systems. One thing I notice is that
all packets either the RST of FIN flag set. Could this be some sort of
race condition where Conntrack removes the connection from the table
because of the flags and as a result the final packet will not get
masqueraded/nat'ed?

Regards,
  Dennis

RE: intermittent nat issue

[Llorente Santos Jesus]

Hi, 
I wouldn't think that is the problem...as far as I know conntrack sets specific timeouts on the connections to match with the actual conntrack state.
You can see these via
sysctl -a |  grep net.netfilter.nf_conntrack_

Best,
Jesus

-----Original Message-----
From: Dennis Jacobfeuerborn [mailto:dennisml@conversis.de] 
Sent: 20 January 2017 12:37
To: Mark Coetser <mark@pkfnet.co.za>; Llorente Santos Jesus <jesus.llorente.santos@aalto.fi>; netfilter@vger.kernel.org
Subject: Re: intermittent nat issue

On 20.01.2017 10:47, Mark Coetser wrote:
> Hi Llorente
> 
> I did run conntrack -F to check that but still had the unnatted 
> packets traversing the interface.
> 

Hi, I'm seeing this as well on our systems. One thing I notice is that all packets either the RST of FIN flag set. Could this be some sort of race condition where Conntrack removes the connection from the table because of the flags and as a result the final packet will not get masqueraded/nat'ed?

Regards,
  Dennis

Re: intermittent nat issue

[Dennis Jacobfeuerborn]

Hi,
when I do a tcpdump of these packets and then immediately look into the
conntrack table I can find no associated entries there suggesting that
the entries have indeed been removed right away without any sort of timeout.

Regards,
  Dennis

On 20.01.2017 16:23, Llorente Santos Jesus wrote:
> Hi, 
> I wouldn't think that is the problem...as far as I know conntrack sets specific timeouts on the connections to match with the actual conntrack state.
> You can see these via
> sysctl -a |  grep net.netfilter.nf_conntrack_
> 
> Best,
> Jesus
> 
> -----Original Message-----
> From: Dennis Jacobfeuerborn [mailto:dennisml@conversis.de] 
> Sent: 20 January 2017 12:37
> To: Mark Coetser <mark@pkfnet.co.za>; Llorente Santos Jesus <jesus.llorente.santos@aalto.fi>; netfilter@vger.kernel.org
> Subject: Re: intermittent nat issue
> 
> On 20.01.2017 10:47, Mark Coetser wrote:
>> Hi Llorente
>>
>> I did run conntrack -F to check that but still had the unnatted 
>> packets traversing the interface.
>>
> 
> Hi, I'm seeing this as well on our systems. One thing I notice is that all packets either the RST of FIN flag set. Could this be some sort of race condition where Conntrack removes the connection from the table because of the flags and as a result the final packet will not get masqueraded/nat'ed?
> 
> Regards,
>   Dennis
> 
> N�����r��y���b�X��ǧv�^�)޺{.n�+���z��׫�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!tml=
> 

Re: intermittent nat issue

[Dennis Jacobfeuerborn]

I filed a bug for this:
https://bugzilla.netfilter.org/show_bug.cgi?id=1115

On 21.01.2017 16:29, Mark Coetser wrote:
> I am seeing this across multiple firewalls that have vlan setups for the
> external links.
> 
> Thank you,
> 
> Mark Adrian Coetser
> mark@pkfnet.co.za
> 
> 
> 
> On 21 January 2017 14:52:41 Andre Cunha <anovaescunha@gmail.com> wrote:
> 
>> I had a similar issue, and in my case I found out that for some reason
>> the
>> external bridge interface had the MAC address as the internal bridge, and
>> this of course was messing with the NAT process.
>>
>> Regards
>> Andre
>>
>>
>> On Sat, Jan 21, 2017 at 1:33 AM, Dennis Jacobfeuerborn <
>> dennisml@conversis.de> wrote:
>>
>>> Hi,
>>> when I do a tcpdump of these packets and then immediately look into the
>>> conntrack table I can find no associated entries there suggesting that
>>> the entries have indeed been removed right away without any sort of
>>> timeout.
>>>
>>> Regards,
>>>   Dennis
>>>
>>> On 20.01.2017 16:23, Llorente Santos Jesus wrote:
>>> > Hi,
>>> > I wouldn't think that is the problem...as far as I know conntrack sets
>>> specific timeouts on the connections to match with the actual conntrack
>>> state.
>>> > You can see these via
>>> > sysctl -a |  grep net.netfilter.nf_conntrack_
>>> >
>>> > Best,
>>> > Jesus
>>> >
>>> > -----Original Message-----
>>> > From: Dennis Jacobfeuerborn [mailto:dennisml@conversis.de]
>>> > Sent: 20 January 2017 12:37
>>> > To: Mark Coetser <mark@pkfnet.co.za>; Llorente Santos Jesus <
>>> jesus.llorente.santos@aalto.fi>; netfilter@vger.kernel.org
>>> > Subject: Re: intermittent nat issue
>>> >
>>> > On 20.01.2017 10:47, Mark Coetser wrote:
>>> >> Hi Llorente
>>> >>
>>> >> I did run conntrack -F to check that but still had the unnatted
>>> >> packets traversing the interface.
>>> >>
>>> >
>>> > Hi, I'm seeing this as well on our systems. One thing I notice is that
>>> all packets either the RST of FIN flag set. Could this be some sort
>>> of race
>>> condition where Conntrack removes the connection from the table
>>> because of
>>> the flags and as a result the final packet will not get
>>> masqueraded/nat'ed?
>>> >
>>> > Regards,
>>> >   Dennis
>>> >
>>> > N?????r??y???b?X??ǧv?^?)޺{.n?+???z??׫?{ay? ʇڙ?,j ??f???h???z? ?w???
>>> ???j:+v???w?j?m???? ????zZ+?????ݢj"??!tml=
>>> >
>>>
>>> -- 
>>> 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
>>>
>