From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751493AbdFYWwN (ORCPT ); Sun, 25 Jun 2017 18:52:13 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:51515 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbdFYWwM (ORCPT ); Sun, 25 Jun 2017 18:52:12 -0400 MIME-Version: 1.0 In-Reply-To: <20170625.114927.1055286919675288173.davem@davemloft.net> References: <20170624021727.17835-1-Jason@zx2c4.com> <20170625.114927.1055286919675288173.davem@davemloft.net> From: "Jason A. Donenfeld" Date: Mon, 26 Jun 2017 00:52:09 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] net/icmp: restore source address if packet is NATed To: David Miller Cc: Netdev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Sun, Jun 25, 2017 at 5:49 PM, David Miller wrote: > This violates things on so many levels. Yes, indeed. > I think this kind of thing need to be hidden inside of netfilter, > it can do the rate limiting and stuff like that in the spot > where it makes the transformation and knows all of the original > addressing and ports. Indeed I'd prefer that, and I'll look again into trying to make that work. But when I tried last, it seemed like there were some insurmountable challenges. With the ratelimiting, the limit has already been applied to one IP -- the masqueraded one -- before netfilter even has a chance to act -- so that IP will already hit the ratelimits well before any additional one inside netfilter would. Then the issue of transformation: last I looked it seemed like icmp_send threw away a bit too much information to do the transformation entirely correctly, but I could be wrong, so I'll give it another look. Hopefully it winds up being as easy as just reverse-transforming ICMP's payload IP header. > > You definitely can't just rewrite header fields here either. The > SKB could be shared, for example. I was afraid of that. It's easy to rework this particular patch, though, if you're still interested in the crufty bolt on approach... But I think I should investigate the netfilter-only approach instead, as you suggested. Jason