Date: Tue, 27 Dec 2016 07:15:15 -0600 From: Jim Thompson <jim@netgate.com> To: "Eugene M. Zheganin" <emz@norma.perm.ru> Cc: FreeBSD Current <freebsd-current@freebsd.org>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: [RFC/RFT] projects/ipsec Message-ID: <CAKAfi7x7dYyVNs6oEd%2BqVV7sKa60RT29rVGt=CEi_s%2BHDsLR0g@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <emz@norma.perm.ru> 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<UP,POINTOPOINT,RUNNING,MULTICAST> 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<PERFORMNUD,AUTO_LINKLOCAL> > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKAfi7x7dYyVNs6oEd%2BqVV7sKa60RT29rVGt=CEi_s%2BHDsLR0g>