Hello!
Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation.
Regards
Daniil Stolnikov.
On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
> Hello!
>
> Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation.
It'd be even better if you could write a patch for us to review.
Cheers,
-PJ
>
> Regards
> Daniil Stolnikov.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Peter P Waskiewicz Jr <[email protected]>
LAN Access Division, Intel Corporation
> On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
>> Hello!
>>
>> Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation.
> It'd be even better if you could write a patch for us to review.
> Cheers,
> -PJ
I was a little not so put it:) I'd certainly be happy and he would write a patch, but I'm afraid do not have the necessary knowledge to implement IPSec Linux. I turned to you, the developers, but rather to urge you to implement this feature using IP range. I hope very much for your help and support. This is especially beneficial for all - the Linux kernel will be more flexible and more compatible with different devices and software.
Regards
Daniil Stolnikov
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr
<[email protected]> wrote:
> On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
>> Hello!
>>
>> Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation.
>
> It'd be even better if you could write a patch for us to review.
oh, come on!
changing addr_match() is trivial for ipv4 and easy for ipv6. :-)
> On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr
> <[email protected]> wrote:
>> On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
>>> Hello!
>>>
>>> Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation.
>>
>> It'd be even better if you could write a patch for us to review.
> oh, come on!
> changing addr_match() is trivial for ipv4 and easy for ipv6. :-)
Is not entirely clear how this function works. It seems that it works again with the subnet bits and comparing the length of the prefix networks.
Probably you mean that you need to add back the comparison ranges? If so, what if we use zywall we do not know the format of the range.
Well, as I said, I badly oriented in the kernel code. I can tell kettle. A change in the function code certainly entail a change in at least the data types passed to the function.
From: Daniil Stolnikov <[email protected]>
Date: Tue, 08 Nov 2011 12:40:13 +0400
> I turned to you, the developers, but rather to urge you to implement
> this feature using IP range.
This won't be implemented, the keys used for IPSEC rule lookups supported by
the kernel are already way too complex.
Ranges can be synthesized by userspace, and that's the way it has to
be supported.
From: Alexey Dobriyan <[email protected]>
Date: Tue, 8 Nov 2011 14:08:24 +0200
> changing addr_match() is trivial for ipv4 and easy for ipv6. :-)
No, this is not happening. This added complexity screws up all the hash table
and lookup optimizations we have in the XFRM layer.
> From: Daniil Stolnikov <[email protected]>
> Date: Tue, 08 Nov 2011 12:40:13 +0400
>> I turned to you, the developers, but rather to urge you to implement
>> this feature using IP range.
> This won't be implemented, the keys used for IPSEC rule lookups supported by
> the kernel are already way too complex.
> From: Alexey Dobriyan <[email protected]>
> Date: Tue, 8 Nov 2011 14:08:24 +0200
>> changing addr_match() is trivial for ipv4 and easy for ipv6. :-)
> No, this is not happening. This added complexity screws up all the hash table
> and lookup optimizations we have in the XFRM layer.
I never imagined that it will cause some difficulties. Several questions arise:
1) How complex is this implementation?
2) How to do this time?
3) Will this feature is implemented vsetaki? If so, how soon and what will it take?
> Ranges can be synthesized by userspace, and that's the way it has to
> be supported.
That is, you want to say that all this can be done at the user level? How so?
In general, if there are alternative implementations of this feature without support at the kernel level? What are some loopholes, tricks? It is meant to create multiple connections to the same subnet subranges without the use of masks such as / 29. Perhaps this can be achieved through l2tp? There, in the present setup IP range. Or is it both?
From: Daniil Stolnikov <[email protected]>
Date: Wed, 9 Nov 2011 09:36:07 +0800
> I never imagined that it will cause some difficulties.
Ever feature has side effects and costs associated with it. Some of
which can be non-trivial.
Like I said, if you want address ranges, ask the userland IPSEC daemon
authors to synthesize it.
I'm really not able to devote the time necessary to explain every
nuance of how we store IPSEC rules in the kernel side database and
what implications that has for expanding the kind of match keys we
support.
David Miller <[email protected]> wrote:
>
> Like I said, if you want address ranges, ask the userland IPSEC daemon
> authors to synthesize it.
Alternatively you can do this with marking and use netfilter
to set the mark.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> Like I said, if you want address ranges, ask the userland IPSEC daemon
> authors to synthesize it.
In this letter, the mailing list http://marc.info/?l=strongswan-users&m=130613736616488&w=4 strongswan-users say that their product has support for IP ranges, but the stack of Linux is based on network masks. So I do not understand how this would work without the support at the kernel level? How will coordination of policies?
Herbert Xu <[email protected]> wrote:
> Alternatively you can do this with marking and use netfilter
> to set the mark.
> Cheers,
We focus on connections to devices zywall. If you choose to zywall IP range as the remote side will not harmonize policies. The connection is not established. And this alternative makes no sense.
Regards
Daniil Stolnikov
Daniil Stolnikov <[email protected]> wrote:
>> Like I said, if you want address ranges, ask the userland IPSEC daemon
>> authors to synthesize it.
>
> In this letter, the mailing list http://marc.info/?l=strongswan-users&m=130613736616488&w=4 strongswan-users say that their product has support for IP ranges, but the stack of Linux is based on network masks. So I do not understand how this would work without the support at the kernel level? How will coordination of policies?
Simple, you break a range policy into parts that can be expressed
as network/mask and install multiple policies. The actual policies
in the kernel just has to have the same effect as the one you
negotiated with the other side, it does not have to look the same.
This is also why you can do the same thing with masks + netfilter.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> Simple, you break a range policy into parts that can be expressed
> as network/mask and install multiple policies. The actual policies
> in the kernel just has to have the same effect as the one you
> negotiated with the other side, it does not have to look the same.
> This is also why you can do the same thing with masks + netfilter.
> Cheers,
Please describe in detail, including the schema and sample configuration files!
The fact that I have already tried some options and I did not. Here is a link to a Russian-language correspondence on my problem: http://www.opennet.ru/openforum/vsluhforumID10/4941.html.
Once again, draw a diagram of which should be implemented:
(server) (client 1)
_______ _______
| | | |---192.168.7.1
| | | |---192.168.7.2
192.168.1.0/24---| |192.168.5.1/24----------------------------192.168.5.2/24| |---192.168.7.3
| | | | |---192.168.7.4
|______| | |______|---192.168.7.5
|
| (client 2)
| _______
| | |---192.168.7.6
| | |---192.168.7.7
-------------------192.168.5.3/24| |---192.168.7.8
| | |---192.168.7.9
| |______|---192.168.7.10
|
| (client 3)
| _______
| | |---192.168.7.11
| | |---192.168.7.12
-------------------192.168.5.4/24| |---192.168.7.13
| |---192.168.7.14
|______|---192.168.7.15
Tried to do the following:
1) network to host. The connection of course been established, but not all traffic be encrypted.
2) host to host. similarly to 1.
3) network to IP range. I tried different configurations, but the connection did not succeed.
So I came to the conclusion that when we point to the IP range zywall IPSec we actually prescribe what kind of traffic will be encrypted. The rest will be routed but no encryption. Correct if I'm wrong.
If you are not working hard to lay out the configuration files!