> 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 time it doesn't allow to create multiple tunnels with VPN hubs that use different 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 production network (as you may know, buiding gre/ipsec 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. 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_at_norma.perm.ru> wrote: > 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 ipsec > stack. When I wrote the message in the freebsd-net ML in the middle of 2012 > (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 sorry > 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 (many > people still use obsoleted legacy interfaceless ipsec approach, not to > mention weird and hybrid software routers like openvpn), but it's definitely > 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 production > 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 already > running one FreeBSD <--> Juniper tunnel at my work: > > # ifconfig ipsec0 > ipsec0: flags=8051<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=21<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 time > it doesn't allow to create multiple tunnels with VPN hubs that use different > 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/ipsec > 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 creates > 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_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org"Received on Tue Dec 27 2016 - 12:15:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC