13 messages, 5 authors, 2011-11-09 · open the first message on its own page
From: Daniil Stolnikov <hidden>
Date: 2011-11-08 03:10:46
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.
From: Peter P Waskiewicz Jr <hidden>
Date: 2011-11-08 06:24:33
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Peter P Waskiewicz Jr [off-list ref] LAN Access Division, Intel Corporation
From: Daniil Stolnikov <hidden>
Date: 2011-11-08 10:52:09
On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:quoted
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
From: Alexey Dobriyan <hidden>
Date: 2011-11-08 12:08:28
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr [off-list ref] wrote:
On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:quoted
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. :-)
From: Daniil Stolnikov <hidden>
Date: 2011-11-08 14:24:23
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr [off-list ref] wrote:quoted
On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:quoted
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: David Miller <davem@davemloft.net>
Date: 2011-11-08 17:16:31
From: Alexey Dobriyan <redacted> 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 <hidden>
Date: 2011-11-09 01:36:25
From: Daniil Stolnikov <redacted> Date: Tue, 08 Nov 2011 12:40:13 +0400
quoted
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 <redacted> Date: Tue, 8 Nov 2011 14:08:24 +0200
quoted
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: David Miller <davem@davemloft.net>
Date: 2011-11-09 01:43:03
From: Daniil Stolnikov <redacted> 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.
From: Herbert Xu <hidden>
Date: 2011-11-09 01:54:20
David Miller [off-list ref] 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 [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Daniil Stolnikov <hidden>
Date: 2011-11-09 02:32:20
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?
From: Daniil Stolnikov <hidden>
Date: 2011-11-09 02:43:20
Herbert Xu [off-list ref] 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
From: Herbert Xu <hidden>
Date: 2011-11-09 03:27:39
Daniil Stolnikov [off-list ref] wrote:
quoted
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 [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Daniil Stolnikov <hidden>
Date: 2011-11-09 07:26:10
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!