From owner-freebsd-current@freebsd.org Tue Dec 27 13:15:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6455AC93330 for ; Tue, 27 Dec 2016 13:15:17 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 39FD41040 for ; Tue, 27 Dec 2016 13:15:17 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-io0-x22e.google.com with SMTP id p42so313144070ioo.1 for ; Tue, 27 Dec 2016 05:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7sNiJQQmAHVAz5l3wOSF/XiGqaxuGZ/BxlwZ9Iwlg1M=; b=RkiOebxEPJiJHS9iHVigB8b/NAwRHchIVXTAAygt3a7HHr56mAt1IVhPW8tLHzvxc9 rhIBahExS3p2rrtG1wpxrl1rEtXSoUueMBc3X2oUrGpXn83vPhO4sBvIO9L6FvfVznYZ wazy2g44erieW46Bn+L30aFjDs4fRylOIZmFM= 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:cc:content-transfer-encoding; bh=7sNiJQQmAHVAz5l3wOSF/XiGqaxuGZ/BxlwZ9Iwlg1M=; b=Gaj+g/saFDssBdGLDFbKOVQOxizu0bppeiQgFwKQqmOP10yuA9q4VAxR3VRbg2Pv47 CZL8fxjmR6sr2PxcXOUUAvmesACi9u7OIzJSaQbaEhGnaWFIirAtfxv7z1xeGu5kQQoL T4VAvpj7liOOYUzzlKRtpea4/rxZa7wV1U/g/qC/GpFrf6syRUsOSA97hJhLxbLCT3C+ WvGzgDoOv5gDZiCxNC3xcmPSLr44XzNfe35w9rkXHDiZkVgw1Oa5tV+wtlRqg9X7keAY 6NvD5zx/Hi5Y/CWFFSpqJL4TaI7VrGc4XwrDymh8/oAsBOZVQ68fUl4N3fCQvaCYwOVV /3cQ== X-Gm-Message-State: AIkVDXKnw9juZuHs/+bGHRa+OTDya6gTTyW20o1pDurDA+3BPgTbUKRPbn2YHB00ijSuXP8FiHtumRhCQFW9Xqih X-Received: by 10.107.28.12 with SMTP id c12mr18917335ioc.223.1482844516394; Tue, 27 Dec 2016 05:15:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.32.4 with HTTP; Tue, 27 Dec 2016 05:15:15 -0800 (PST) In-Reply-To: <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> References: <2bd32791-944f-2417-41e9-e0fe1c705502@FreeBSD.org> <5889f1f5-5585-95d4-beac-285dbc722b4e@norma.perm.ru> From: Jim Thompson Date: Tue, 27 Dec 2016 07:15:15 -0600 Message-ID: Subject: Re: [RFC/RFT] projects/ipsec To: "Eugene M. Zheganin" Cc: FreeBSD Current , freebsd-net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 27 Dec 2016 13:30:07 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 13:15:17 -0000 > In it's initial state if_ipsec allows to use only one set of encryption p= arameters (because only one sainfo anonyumous is possible), so at this time= it doesn't allow to create multiple tunnels with VPN hubs that use differe= nt cipers and/or transform sets, but as far as I understand this is subject= to change and Andrey is already working on a support of this feature from = ipsec-tools IKE daemon. pfSense (which you mention below) is using strongswan, so when Andrey is finished with ipsec-tools, we will need to review his changes and see what we can do for strongswan. I'm looking forward to the mutliple-tunnel support, which is required for pfSense. > But even in this state this feature is already useful and I'm excited to = see it commited to HEAD and then MFC'd to 11.x, to start using it in my pro= duction network (as you may know, buiding gre/ipsec tunnels on Juniper is v= ery hackish and tricky, bit I still have more than dozen of them). I've alr= eady saw a discussion on FreeBSD web forums, and people there are excited a= bout if_ipsec too. > Furthermore, I believe that guys using pfSense will be very happy about i= f_ipsec in their routers, because I saw several discussions mentioning miss= ing VTI support there. I'm not sure what discussions you saw. We're aware, and very interested in the VTI support. https://twitter.com/gonzopancho/status/809412164259893248 On Wed, Dec 14, 2016 at 10:52 AM, Eugene M. Zheganin wr= ote: > Hi, > > On 11.12.2016 4:07, Andrey V. Elsukov wrote: >> >> Hi All, >> >> I am pleased to announce that projects/ipsec, that I started several >> months ago is ready for testing and review. >> The main goals were: >> * rework locking to make IPsec code more friendly for concurrent >> processing; >> * make lookup in SADB/SPDB faster; >> * revise PFKEY implementation, remove stale code, make it closer >> to RFC; >> * implement IPsec VTI (virtual tunneling interface); >> * make IPsec code loadable as kernel module. >> >> Currently all, except the last one is mostly done. So, I decided ask for >> a help to test the what already done, while I will work on the last task= . >> > Well, at last FreeBSD got one of the most anticipated features in it's ip= sec > stack. When I wrote the message in the freebsd-net ML in the middle of 20= 12 > (https://lists.freebsd.org/pipermail/freebsd-net/2012-June/032556.html) I > had a very little hope that someone will actually implement this, and now > I'm very grateful that Andrey got the time to do this (and I'm really sor= ry > for being such a pain in the ass, I'm saying so because I was bothering > Andrey all this time in IRC). This isn't definitely a feature that every > FreeBSD enthusiast will use, and, sadly, even not the feature that every > network engineer that use ipsec in it's every day work will configure (ma= ny > people still use obsoleted legacy interfaceless ipsec approach, not to > mention weird and hybrid software routers like openvpn), but it's definit= ely > a feature that will be appreciated by every skilled L3 VPN engineer that = is > using FreeBSD in it's operating stack. I've ran some tests in my producti= on > network and I should say that even on it's initial release state if_ipsec= is > fully operational with Juniper st tunnel on the other side, so I'm alread= y > running one FreeBSD <--> Juniper tunnel at my work: > > # ifconfig ipsec0 > ipsec0: flags=3D8051 metric 0 mtu 1400 > tunnel inet 128.127.144.19 --> 128.127.146.1 > inet 172.16.3.104 --> 172.16.3.105 netmask 0xffffffff > inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9 > nd6 options=3D21 > reqid: 16385 > groups: ipsec > > racoon.conf: > path pre_shared_key "/usr/local/etc/racoon/psk.txt"; > > padding { > maximum_length 20; # maximum padding length. > randomize off; # enable randomize length. > strict_check off; # enable strict check. > exclusive_tail off; # extract last one octet. > } > > listen { > isakmp 128.127.144.19 [500]; > strict_address; # requires that all addresses must be bound. > } > > timer { > counter 5; > interval 20 sec; > persend 1; > > phase1 30 sec; > phase2 15 sec; > } > > # > # SPb, Test > # > > remote 128.127.146.1 { > exchange_mode main; > lifetime time 1 hour; > my_identifier address 128.127.144.19; > peers_identifier address 128.127.146.1; > passive off; > proposal_check obey; > dpd_delay 20; > proposal { > encryption_algorithm des; > hash_algorithm md5; > authentication_method pre_shared_key; > dh_group modp768; > } > } > > # > # SPb, Test > # > > sainfo address 0.0.0.0/0 [500] any address 0.0.0.0/0 [500] any { > pfs_group modp768; > lifetime time 60 min; > encryption_algorithm des; > authentication_algorithm non_auth; > compression_algorithm deflate; > } > > Juniper side: > >> show configuration interfaces st0.147 > description "Perm, FreeBSD Test Server"; > family inet { > mtu 1455; > address 172.16.3.105/32 { > destination 172.16.3.104; > } > } > >> show configuration security ike policy kosm65 > proposals norma-ike; > pre-shared-key ascii-text > "$9$-SV4ZUDkqPQUjBIclLXgoJUqf9CuESeAp-w2gGUjHqfQn"; ## SECRET-DATA > >> show configuration security ike gateway kosm65-freebsd-test > ike-policy perm-freebsd-test; > address 128.127.144.19; > local-identity inet 128.127.146.1; > remote-identity inet 128.127.144.19; > external-interface reth1.2; > >> show configuration security ipsec vpn kosm65-freebsd-test > bind-interface st0.147; > ike { > gateway kosm65-freebsd-test; > ipsec-policy norma-policy; > } > >> show configuration security ipsec policy norma-policy > perfect-forward-secrecy { > keys group1; > } > proposals norma-ipsec; > >> show configuration security ipsec proposal norma-ipsec > protocol esp; > encryption-algorithm des-cbc; > lifetime-seconds 600; > >> show configuration security ike proposal norma-ike > authentication-method pre-shared-keys; > dh-group group1; > authentication-algorithm md5; > encryption-algorithm des-cbc; > > In it's initial state if_ipsec allows to use only one set of encryption > parameters (because only one sainfo anonyumous is possible), so at this t= ime > it doesn't allow to create multiple tunnels with VPN hubs that use differ= ent > cipers and/or transform sets, but as far as I understand this is subject = to > change and Andrey is already working on a support of this feature from > ipsec-tools IKE daemon. But even in this state this feature is already > useful and I'm excited to see it commited to HEAD and then MFC'd to 11.x,= to > start using it in my production network (as you may know, buiding gre/ips= ec > tunnels on Juniper is very hackish and tricky, bit I still have more than > dozen of them). I've already saw a discussion on FreeBSD web forums, and > people there are excited about if_ipsec too. Furthermore, I believe that > guys using pfSense will be very happy about if_ipsec in their routers, > because I saw several discussions mentioning missing VTI support there. > > It's very easy to configure, because it uses ifconfig syntax and it creat= es > all the needed policies in the SADB automatically, so one less thing to > bother with. And when I say "fully opertational with Juniper" I mean it: = no > tricky or hackish configuration directives are required oin the Juniper > side, everything is like it's a Juniper or Cisco on the other side. So I'= m > pretty sure this will work with Cisco too (didn't run any test with Cisco > though). > > Once again, I thank Andrey for this. > > Eugene. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"