From owner-freebsd-net@freebsd.org Tue Feb 27 11:20:44 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 3A34DF3B9A3 for ; Tue, 27 Feb 2018 11:20:44 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C22CB6FE27 for ; Tue, 27 Feb 2018 11:20:43 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id w1RBKgO2006080; Tue, 27 Feb 2018 12:20:42 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 569E9D77; Tue, 27 Feb 2018 12:20:42 +0100 (CET) Message-ID: <5A953F09.2040503@omnilan.de> Date: Tue, 27 Feb 2018 12:20:41 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Andrey V. Elsukov" CC: freebsd-net@freebsd.org Subject: Re: if_ipsec(4) and IKEv1 [security/ipsec-tools, racoon.conf] References: <5A952B38.8060007@omnilan.de> <04174d98-c35d-b88b-d0db-ac579b153c57@yandex.ru> In-Reply-To: <04174d98-c35d-b88b-d0db-ac579b153c57@yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 130 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 27 Feb 2018 12:20:42 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 11:20:44 -0000 Bezüglich Andrey V. Elsukov's Nachricht vom 27.02.2018 11:50 (localtime): > On 27.02.2018 12:56, Harry Schmalzbauer wrote: >> Hello, >> >> I'm out of ideas how to quick-start with if_ipsec(4) and IKEv1. >> >> I'm familar with security/ipsec-tools, but I couldn't find out how >> racoon(8) would interact with cloned if_ipsec(4) interfaces yet. > > You need to manually configure if_ipsec interface, i.e. assign tunnel > addresses and bring it up. After that you need to configure racoon to > reply for ACQUIRE messages when some traffic will go trough configured > tunnel. So, you configure if_ipsec tunnel and it creates security > policies, these policies will produce ACQUIRE requests to racoon and > racoon should reply and this will produce needed security associations. > >> Also, how to tell racoon(8) to generate such tunnel interfaces, hence >> policies? >> I guess the latter isn't implemented in racoon(8) (yet). > > I think there are not any IKE daemons that can do this. > >> But is racoon(8) supposed to work with static policies generated by >> if_ipsec(4)? > > Yes, at least for one tunnel it worked for me. Probably it is possible > for several tunnels too. Thank you very much for your explanation! Unfortunately, I couldn't get the P2P idea behind if_ipsec(4) and I tought I'd just need a few minutes to switch from policy based tunnels to route based – local brain contraints seem to require me much more time... My intention was to incorporate ALTQ for ESP payload. So my idea was, that I have if_ipsec(4) and utilize pf's queue feature. But I have to stop here since I need time to think about if_ipsec(4). Maybe others have similar questions, so I just post them at this point, and because I will have forgotten next week otherwise: Is the P2P definition (ifconfig ipsecX ipnum/mask ipnum) meant as transfer network? If so, why would I want a local IP with a mask other than 0xffffffff? And why should the destination belong to the same subnet in that case? I'm completely missing something here... Also, I don't understand why if_ipsec(4) generates ipsec policies defined as 0.0.0.0/0[any] 0.0.0.0/0[any]. For sure, that's handled differently than the policies I'm aware about, because there's scope=ifnet and ifname, but I need some time to elaborate the reasons for the way if_ipsec(4) is how it is. Are there any 3rd-vendor papers, describing a similar implementation convention? Thanks, -Harry