From owner-freebsd-net@freebsd.org Thu May 17 17:28:24 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AF74EDA430 for ; Thu, 17 May 2018 17:28:24 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4C766B9FA for ; Thu, 17 May 2018 17:28:23 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id x66-v6so3174534vka.11 for ; Thu, 17 May 2018 10:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=H2UwVQDQ19i3SHkP+ufx24fn0PC1nKxbE4LXs70FhCI=; b=mVnsYaoxKUV2oG/patFffUOHwMCWIo+u2nVolhk3vwtwY4otUGkXzIimTKUh7hY6tF tCqO5hhGj1cf8OLMXkfEzxcKEGD4dAzwaL3omVqY2T+rLblCwgOngxWgUy3oAEHH8G6Z eDZPMed8wdCHhGpSBJNzWZCwDRalimEvY4f99a6jf0kVCVPSazGOJVxT4+bu179rNRPH 7ROiJDgz0Uj3Ay45haqBJhDVPbYhAnfG4bKuWQB13t1ipHkNviSorA/hJ7FaVZ3QfpIL jc6xYrdOMfTHKh6Z/OERn7VC7kr8pg+gVGJrXmdxgymvLdySYIJvAoxRoFVdxODdKAl+ bFUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=H2UwVQDQ19i3SHkP+ufx24fn0PC1nKxbE4LXs70FhCI=; b=Fqo65djbJLBH6FgY0uCxrVv7pzXgLsF/9UZA0o65aMVLt1jrJKkmwZ5LwvoHPV8792 lqo3ggDWNwSv4zhXry4hSWMXzEBabD+rrYLziupJXq2vjObu9B1gKBd0bm/8lqUjQsvX hOLFgP47xn8RGq8pRUHyL5eDHLgEk220Wfg5o3wLi+wB5eb2z1H0GnUNEWrVUm2lIAsg +SjwXTQbVnNtnlmK/HMZqXbOeBPwZLqtiXIXS+OR5YJZ/6BwFEhWnfSjzre3qRbyLZIq k3DMsQ/Q5K3lkoJXGzDnXTNcgQyUpTzFgku1qWfYerYRQHlMj3ehqR+gjSWGJrxmbtPB a9dA== X-Gm-Message-State: ALKqPwfPb/MtjhcwMKapFoxv+YxcWdP4jiDSvZ0dxMbWyZKOqEcZ7bOK ycM5cnoQ6oLQbJZscwK7X4ID+iRpDwnPN/7LbpM2lW+v X-Google-Smtp-Source: AB8JxZqsnUzclqXIXJyY+A+b6NzLsVZJnm3tebp0ou9CAorbUK4hkmXUzkCACWcQwqiO3xAAy72bI4zSss6P/CSfyM0= X-Received: by 2002:a1f:8749:: with SMTP id j70-v6mr4694208vkd.57.1526578102920; Thu, 17 May 2018 10:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.91.22 with HTTP; Thu, 17 May 2018 10:28:22 -0700 (PDT) In-Reply-To: <9a64e1e8-2258-379e-9ed0-4c8d8bf0aea9@yandex.ru> References: <951ef6f6-95d8-8832-1e7a-59fc90434029@gmail.com> <9a64e1e8-2258-379e-9ed0-4c8d8bf0aea9@yandex.ru> From: Andreas Scherrer Date: Thu, 17 May 2018 19:28:22 +0200 Message-ID: Subject: Re: Site-to-site IPSec VPN using if_ipsec and racoon To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 17:28:24 -0000 Dear Andrey Thank you for your reply. I was able to find a configuration that establishes the IPSec tunnel now! It was a bit of a trial and error and I have tried/changed several things; so I am not 100% sure what the minimum set of changes required would have been, but I think I understand that it comes down to the SPD entries. That is also the main reason I am writing this, maybe it will help someone at some point. When if_ipsec is used, automatic entries in the SPD are made (for 0.0.0.0/0 <-> 0.0.0.0/0 via ipsecX). That works, because everything that ends up on ipsecX should be encrypted. But I am not using if_ipsec (or even FreeBSD) on the "remote" side. It is libreswan running on Linux/Raspbian there. And libreswan does not have (and also cannot have) an SPD entry for 0.0.0.0/0 <-> 0.0.0.0/0. So the two ends could never complete phase 1... I ended up still manually creating *additional* ("more specific" and matching with what I have in libreswan) SPD entries on FreeBSD using setkey and now things work. Thank you! andreas On 13 May 2018 at 02:02, Andrey V. Elsukov wrote: > On 13.05.2018 02:37, Andreas Scherrer wrote: > > My interpretation of [2]'s statement: > > > > "If no security association is found, the packet is put on hold and the > > IKE daemon is asked to negotiate an appropriate one." > > > > is that it should somehow be automagic. But in my current configuration, > > that does not happen. I never see FreeBSD initiate any IKE traffic > > (500/udp) and 'setkey -D' always reports "No SAD entries.". > > Hi, > > You need to run racoon in debug mode and then, I think, you will see how > ACQUIRE happens, and why it doesn't work. > > > Can anybody point me in the right direction (be it more documentation or > > a working config example)? That would be awesome. > > Recently there was the discussion about it, and a config that worked for > one tunnel was published: > https://lists.freebsd.org/pipermail/freebsd-net/2018-April/050271.html > > You can read the entire topic to get additional info. > > > Best regards > > andreas > > > > Ps.: I have tried the "old" approach which I know better using 'gif' > > interfaces. With that I have managed to get racoon negotiate SAs for the > > same tunnel (i.e. with libreswan on the RPi). Unfortunately I cannot > > wrap my head around the routing with that approach (no 'gif' on > > Raspbian). And the documentation also mentions this as a limitation of > > 'gif' [3]: "you cannot usually use gif to talk with IPsec devices that > > use IPsec tunnel mode" > > You can use gif+IPsec in transport mode from one side, and IPsec device > with tunnel mode from other side. Technically this is the same. But I > don't know how hard configure this using IKE. > > -- > WBR, Andrey V. Elsukov > >