From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751858AbcF3ApG (ORCPT ); Wed, 29 Jun 2016 20:45:06 -0400 Received: from wolff.to ([98.103.208.27]:35708 "HELO wolff.to" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751450AbcF3ApB (ORCPT ); Wed, 29 Jun 2016 20:45:01 -0400 X-Greylist: delayed 456 seconds by postgrey-1.27 at vger.kernel.org; Wed, 29 Jun 2016 20:44:12 EDT Date: Wed, 29 Jun 2016 19:34:58 -0500 From: Bruno Wolff III To: linux-kernel@vger.kernel.org Subject: Re: [RFC] WireGuard: next generation secure network tunnel Message-ID: <20160630003458.GA7581@wolff.to> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 28, 2016 at 16:49:18 +0200, "Jason A. Donenfeld" wrote: > >Today I'm releasing WireGuard, an encrypted and authenticated >tunneling virtual interface for the kernel. It uses next-generation 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. 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. This seems much easier to use than ipsec and should be faster than tunnelling over ssh or openvpn.