From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932139AbcGAXDR (ORCPT ); Fri, 1 Jul 2016 19:03:17 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:46339 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932070AbcGAXDQ (ORCPT ); Fri, 1 Jul 2016 19:03:16 -0400 Subject: Re: [RFC] WireGuard: next generation secure network tunnel To: bruno@wolff.to References: In-Reply-To: From: "Jason A. Donenfeld" Cc: LKML Message-ID: Date: Sat, 2 Jul 2016 01:03:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Bruno, Sorry I didn't reply to this earlier; the message didn't make it to me somehow. Bruno Wolff III writes: > I tried this out on 4.7 kernels and it seemed to work OK. I can't tell > about security, but the packets made it to where they are going. Happy to hear! > > My eventual use case, is to be able to reach a machine behind NAT by going > though a fixed machine in another location. The machine behind NAT will > keep a tunnel usable by occasionally pinging through the tunnel to make > sure that NAT has state information allowing packets to make it back and > that the fixed machine knows where to send packets. That seems like a setup that would work fine. > > This seems much easier to use than ipsec and should be faster than > tunnelling over ssh or openvpn. Absolutely! That's the goal. Thanks for the feedback, Jason