Re: [RFC/RFT] projects/ipsec
On 06.02.2017 16:27, peter.b...@bsd4all.org wrote: Andrey, Is this going to MFC'ed to stable-11 in the future? I have tested with current and found no issues, but I would like to add it to a semi-production environment running stable-11 Hi, I thought to make MFC after a month or two, but I didn't seen any information when 11.1-RELEASE is planned. So, I don't know when feature freeze begins. Also there are some changes that can be considered as POLA violation, especially the single name space for SPI can affect some users. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
Andrey, Is this going to MFC'ed to stable-11 in the future? I have tested with current and found no issues, but I would like to add it to a semi-production environment running stable-11 Peter > On 6 Feb 2017, at 10:07, Andrey V. Elsukov wrote: > > On 11.12.2016 02:07, Andrey V. Elsukov wrote: >> 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. > > JFYI, the project was merged into head/ in r313330. > > -- > WBR, Andrey V. Elsukov > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 11.12.2016 02:07, Andrey V. Elsukov wrote: 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. JFYI, the project was merged into head/ in r313330. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
11.12.2016 01:07, Andrey V. Elsukov пишет:
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.
How to try? There are no patches, you need to checkout the full
projects/ipsec source tree, and build the kernel and the base system.
There are very few changes in the base system, mostly the kernel
changes. Thus for testing that old configuration is still work, it is
enough to build only the kernel.
The approximate list of changes that may be visible to users:
* SA bundles now can have only 4 items in the chain. I think it is
enough, I can't imagine configurations when needed more. Also now SA
bundles supported for IPv6 too.
* due to changes in SPDB/SADB, systems where large number of SPs and SAs
are in use should get significant performance benefits.
* the memory consumption should slightly increase. There are several
hash tables and SP cache appeared.
* INPCB SP cache should noticeable increase network performance of
application when security policies are presence.
https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html
* use transport mode IPsec for forwarded IPv4 packets now unsupported.
This matches the IPv6 behavior, and since we can handle the replies, I
think it is useless.
* Added net.inet.ipsec.check_policy_history sysctl variable. When it is
set, each inbound packet that was handled by IPsec will be checked
according to matching security policy. If not all IPsec transforms were
applied, the check will fail, and packet will be dropped.
* Many PF_KEY messages handlers was updated, probably some IKEd now may
fail due to stricter checks.
* SPI now unique for each SA. This also can break something.
* Added if_ipsec interface. For more info look at
https://svnweb.freebsd.org/base?view=revision&revision=309115
https://reviews.freebsd.org/P112
* TCP_SIGNATURE code was reworked and now it behaves closer to RFC
https://svnweb.freebsd.org/base?view=revision&revision=309610
* NAT-T support was reworked.
https://svnweb.freebsd.org/base?view=revision&revision=309808
Also I made the patch to racoon that adds better support of NAT-T,
you can use this port to build patched racoon:
https://people.freebsd.org/~ae/ipsec-tools.tgz
What results is interesting to me?
If you have some nontrivial configuration, please test.
If you have some configuration, that did't work, please test this branch.
If you have performance problems, please test. But don't forget that
this is head/ branch, you need to disable all debugging first.
If you just want to test, pay attention to the output of
`vmstat -m | egrep "sec|sah|pol|crypt"`.
If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this
support was significantly changed.
PS. I just updated the branch to last head/, and it was not tested, sorry :)
Hi, nothing unusual, all works fine. Strangswan in tunnel mode on current:
root@thinkpad:/home/shurik # ipsec status
Security Associations (1 up, 0 connecting):
ikev2-client[1]: ESTABLISHED 3 minutes ago,
10.1.1.183[xxx..org.ua]...xxx.yyy.74.7[xxx..org.ua]
ikev2-client{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs:
c6f68157_i c6d17c85_o
ikev2-client{1}: 10.10.10.2/32 === 0.0.0.0/0
--
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
Hi All, I ported the changes from projects/ipsec to stable/11 branch. So, if it is more suitable for testing, please, welcome. You can checkout the sources from github: https://github.com/bu7cher/freebsd/tree/stable/11 Also I made the standalone patch: https://people.freebsd.org/~ae/ipsec.diff Unfortunately, I did only compile test for stable branch. 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. How to try? There are no patches, you need to checkout the full projects/ipsec source tree, and build the kernel and the base system. There are very few changes in the base system, mostly the kernel changes. Thus for testing that old configuration is still work, it is enough to build only the kernel. The approximate list of changes that may be visible to users: * SA bundles now can have only 4 items in the chain. I think it is enough, I can't imagine configurations when needed more. Also now SA bundles supported for IPv6 too. * due to changes in SPDB/SADB, systems where large number of SPs and SAs are in use should get significant performance benefits. * the memory consumption should slightly increase. There are several hash tables and SP cache appeared. * INPCB SP cache should noticeable increase network performance of application when security policies are presence. https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. * Added net.inet.ipsec.check_policy_history sysctl variable. When it is set, each inbound packet that was handled by IPsec will be checked according to matching security policy. If not all IPsec transforms were applied, the check will fail, and packet will be dropped. * Many PF_KEY messages handlers was updated, probably some IKEd now may fail due to stricter checks. * SPI now unique for each SA. This also can break something. * Added if_ipsec interface. For more info look at https://svnweb.freebsd.org/base?view=revision&revision=309115 https://reviews.freebsd.org/P112 * TCP_SIGNATURE code was reworked and now it behaves closer to RFC https://svnweb.freebsd.org/base?view=revision&revision=309610 * NAT-T support was reworked. https://svnweb.freebsd.org/base?view=revision&revision=309808 Also I made the patch to racoon that adds better support of NAT-T, you can use this port to build patched racoon: https://people.freebsd.org/~ae/ipsec-tools.tgz What results is interesting to me? If you have some nontrivial configuration, please test. If you have some configuration, that did't work, please test this branch. If you have performance problems, please test. But don't forget that this is head/ branch, you need to disable all debugging first. If you just want to test, pay attention to the output of `vmstat -m | egrep "sec|sah|pol|crypt"`. If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this support was significantly changed. IPsec as kernel modules was reported here: https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046762.html Some additional testing also needed with this... -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 09.01.2017 14:38, Bjoern A. Zeeb wrote: On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a proper review that way. I would very much prefer this to be (a) either become stable first and then give people a chance, or (b) see if you can break out small self-contained changes put them up into review and merge them piece by piece making it a lot easier to convince ourselves that things still look good. Hi, yes, I hope I have fixed all found issues, now I will test the changes in our environment. I prefer the first way (a), because another splitting into small pieces requires a lot of time that I don't have. So, if you want to do a review, you are welcome :) Now I'll be focused on testing with different IKEd, documenting the changes, and fixing possible NO_INET/NO_INET6 related build issues. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a proper review that way. I would very much prefer this to be (a) either become stable first and then give people a chance, or (b) see if you can break out small self-contained changes put them up into review and merge them piece by piece making it a lot easier to convince ourselves that things still look good. /bz ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On Tue, Dec 27, 2016 at 6:10 AM, Andrey V. Elsukov wrote: > On 27.12.2016 16:15, Jim Thompson wrote: > >> 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. >> > > There are no such limits. You can create multiple VTI interfaces. > The problem is in with racoon configuration restrictions. It looks like > ipsec-tools project is dead, I didn't received any replies from > ipsec-tools-devel mailing list. > > I'm not aware how to configure strongswan, so if someone will not try to > do this, I don't know when I will do this. > > Strongswan already supports this. Just the FreeBSD code for it is not there due to the missing feature until now. > -- > WBR, Andrey V. Elsukov > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > -- > Ermal > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 27.12.2016 16:15, Jim Thompson wrote: 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. There are no such limits. You can create multiple VTI interfaces. The problem is in with racoon configuration restrictions. It looks like ipsec-tools project is dead, I didn't received any replies from ipsec-tools-devel mailing list. I'm not aware how to configure strongswan, so if someone will not try to do this, I don't know when I will do this. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
> 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 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 metric 0 mtu 1400
> tunnel inet 128.127.144.19 --> 128.127.146.1
> inet 172.16.3.104 --> 172.16.3.105 netmask 0x
> inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9
> nd6 options=21
> 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
> descript
Re: [RFC/RFT] projects/ipsec
On 11.12.2016 02: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. I finished the last task, now it is possible to load/unload IPsec and TCP-MD5 support as kernel modules. New kernel option IPSEC_SUPPORT should be used to build the kernel that is able to load IPsec module. So, if you have 'options IPSEC' in the kernel config, IPsec support will be build in the kernel without TCP-MD5 support. If you have 'options IPSEC' and 'options TCP_SIGNATURE', IPsec and TCP-MD5 support will be build in the kernel. If you have 'options IPSEC' and 'options IPSEC_SUPPORT', IPsec support will be build in the kernel and TCP-MD5 can be loaded. If you have 'options IPSEC_SUPPORT', IPsec and TCP-MD5 can be loaded. If you have 'options IPSEC_SUPPORT' and 'options TCP_SIGNATURE', TCP-MD5 support will be build in the kernel and IPsec can be loaded. If you have not IPSEC* options, it isn't possible to use IPsec as module. So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
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 metric 0 mtu 1400
tunnel inet 128.127.144.19 --> 128.127.146.1
inet 172.16.3.104 --> 172.16.3.105 netmask 0x
inet6 fe80::204:23ff:fec7:194d%ipsec0 prefixlen 64 scopeid 0x9
nd6 options=21
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 m
Re: [RFC/RFT] projects/ipsec
On Sun, Dec 11, 2016 at 12:07 AM, 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. > > I've got a very simple configuration (static key),but I like the performance improvement brings by projects/ipsec :-) A simple packet-per-second using null encryption should be enough for benching the improvement, but my IPSec lab (using Equilibrium methodology) did a little more. https://github.com/ocochard/netbenches/blob/master/AMD_GX- 412TC_4Cores_Intel_i210AT/ipsec/results/fbsd12.projects- ipsec.equilibrium/graph.png Thanks for your work! Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[RFC/RFT] projects/ipsec
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. How to try? There are no patches, you need to checkout the full projects/ipsec source tree, and build the kernel and the base system. There are very few changes in the base system, mostly the kernel changes. Thus for testing that old configuration is still work, it is enough to build only the kernel. The approximate list of changes that may be visible to users: * SA bundles now can have only 4 items in the chain. I think it is enough, I can't imagine configurations when needed more. Also now SA bundles supported for IPv6 too. * due to changes in SPDB/SADB, systems where large number of SPs and SAs are in use should get significant performance benefits. * the memory consumption should slightly increase. There are several hash tables and SP cache appeared. * INPCB SP cache should noticeable increase network performance of application when security policies are presence. https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. * Added net.inet.ipsec.check_policy_history sysctl variable. When it is set, each inbound packet that was handled by IPsec will be checked according to matching security policy. If not all IPsec transforms were applied, the check will fail, and packet will be dropped. * Many PF_KEY messages handlers was updated, probably some IKEd now may fail due to stricter checks. * SPI now unique for each SA. This also can break something. * Added if_ipsec interface. For more info look at https://svnweb.freebsd.org/base?view=revision&revision=309115 https://reviews.freebsd.org/P112 * TCP_SIGNATURE code was reworked and now it behaves closer to RFC https://svnweb.freebsd.org/base?view=revision&revision=309610 * NAT-T support was reworked. https://svnweb.freebsd.org/base?view=revision&revision=309808 Also I made the patch to racoon that adds better support of NAT-T, you can use this port to build patched racoon: https://people.freebsd.org/~ae/ipsec-tools.tgz What results is interesting to me? If you have some nontrivial configuration, please test. If you have some configuration, that did't work, please test this branch. If you have performance problems, please test. But don't forget that this is head/ branch, you need to disable all debugging first. If you just want to test, pay attention to the output of `vmstat -m | egrep "sec|sah|pol|crypt"`. If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this support was significantly changed. PS. I just updated the branch to last head/, and it was not tested, sorry :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
