lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 15 Aug 2011 18:27:13 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	David Hill <hilld@...arystorm.net>
cc:	Florian Mickler <florian@...kler.org>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	bugzilla-daemon@...zilla.kernel.org
Subject: Re: Fw: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to
 be broken.


	Hello,

On Fri, 5 Aug 2011, David Hill wrote:

> Hello Julian,
> 
>    I'm not using TPROXY and I've used a blank firewall with only masquerading
> and reproduced the issue.
> Nothing is in NAT/mangle nor OUTPUT  but the rules mentionned in the attached
> files to this bug.
> 
> Francis Whittle  (Comment #18) has the same issue.
> 
> > Hello,
> > 
> > On Thu, 4 Aug 2011, Florian Mickler wrote:
> > 
> > > Can someone take a look at this regression?
> > > 
> > > Begin forwarded message:
> > > 
> > > Date: Thu, 28 Jul 2011 04:51:12 GMT
> > > From: bugzilla-daemon@...zilla.kernel.org
> > > To: florian@...kler.org
> > > Subject: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be
> > > broken.
> > > 
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=39132
> > 
> > So, problem points again to
> > "Fix ip_route_me_harder triggering ip_rt_bug" ? May be
> > David C. Hill or Florian can provide some information, eg. is
> > tproxy used, what NAT rules are used, any rules in OUTPUT
> > hooks (NAT/mangle) and which packets are dropped.

	May be it is a sequence of two problems. I now
checked the tcpdump log from Francis Whittle. The
"seq 352:1792" packet at 18:44:29.235154 that is not
SNAT-ed is long, can it be some PMTU event that triggers
ICMP response to the internal host? Because I see changes
in MSS. May be rc5 triggers ICMP FRAG NEEDED while rc6
does not. It can happen because:

1. ICMP uses non-local iph->saddr when XFRM is compiled,
reverse lookup fails with ENOENT but fl4->saddr is
already damaged with the original daddr (non-local).

	Fix is here: http://marc.info/?t=131118984300003&r=1&w=2

2. The patched ip_route_me_harder between 3.0-rc5 and
3.0-rc6 expects that sockets always provide local address.
This is wrong for some cases such as TCP (uses different
SOCK_RAW socket for some packets and can cause problem
for tproxy), RAW (can use spoofed sources) and now the
ICMP code that incorrectly provides non-local address.

	Fix is here: http://marc.info/?t=131274411600001&r=1&w=2

	I hope (any of) these two fixes should solve the
masquerading problems. If that is not true, tcpdump from rc5
would be helpful for comparison.

Regards

--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ