> 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 <e...@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
