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 faste
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/S
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
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 prop
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 pre
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 multipl
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,
> 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
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/S
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
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;
On 11.12.2016 18:28, Slawa Olhovchenkov wrote:
>> I already described how it works and that you can configure what
>> you want.
>>
>> https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046616.html
>
> This is don't clean about "we can't handle the returned packets".
> If we can handle
On Sun, Dec 11, 2016 at 03:53:49PM +0300, Andrey V. Elsukov wrote:
> On 11.12.2016 15:50, Slawa Olhovchenkov wrote:
> >> You can specify what you want, but this just will not work as you
> >> expect. A router usually must not handle all TCP sessions that it
> >
> > You mean forward to IPSec syste
On 11.12.2016 15:50, Slawa Olhovchenkov wrote:
>> You can specify what you want, but this just will not work as you
>> expect. A router usually must not handle all TCP sessions that it
>
> You mean forward to IPSec system only packets with DST_IP = my_ip?
> I that case, why you talk only about not
On Sun, Dec 11, 2016 at 03:19:24PM +0300, Andrey V. Elsukov wrote:
> On 11.12.2016 15:15, Slawa Olhovchenkov wrote:
> >> IPsec is a set of protocol handlers - ESP/AH/IPcomp. Inbound packets are
> >> handled by security association with given destination address and SPI.
> >> If returned packets ar
On 11.12.2016 15:15, Slawa Olhovchenkov wrote:
>> IPsec is a set of protocol handlers - ESP/AH/IPcomp. Inbound packets are
>> handled by security association with given destination address and SPI.
>> If returned packets aren't destined to your address, protocol handlers
>> will not handle them.
>
On Sun, Dec 11, 2016 at 03:09:28PM +0300, Andrey V. Elsukov wrote:
> On 11.12.2016 14:58, Slawa Olhovchenkov wrote:
> >> No. An encapsulated by gif(4) packet is considered as own packet. The
> >> described change is related to transport mode policies, that are match
> >> forwarded packets, i.e. wh
On 11.12.2016 14:58, Slawa Olhovchenkov wrote:
>> No. An encapsulated by gif(4) packet is considered as own packet. The
>> described change is related to transport mode policies, that are match
>> forwarded packets, i.e. when source and destination addresses are not
>> our own. In this case we can'
On Sun, Dec 11, 2016 at 02:33:43PM +0300, Andrey V. Elsukov wrote:
> On 11.12.2016 12:13, Eugene Grosbein wrote:
> > 11.12.2016 6:07, Andrey V. Elsukov пишет:
> >
> >> * use transport mode IPsec for forwarded IPv4 packets now unsupported.
> >> This matches the IPv6 behavior, and since we can hand
On 11.12.2016 12:13, Eugene Grosbein wrote:
> 11.12.2016 6:07, Andrey V. Elsukov пишет:
>
>> * 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.
>
> Does it include a case of packe
11.12.2016 6:07, Andrey V. Elsukov пишет:
* 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.
Does it include a case of packets going from LAN and forwarded into gif(4)
tunnel
connec
21 matches
Mail list logo