netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniil Stolnikov <danila.st@mail.ru>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	<linux-crypto@vger.kernel.org>,
	<linux-security-module@vger.kernel.org>, <davem@davemloft.net>,
	<adobriyan@gmail.com>, <peter.p.waskiewicz.jr@intel.com>,
	<davem@davemloft.net>
Subject: Re: Add IPSec IP Range in Linux kernel
Date: Wed, 9 Nov 2011 15:25:58 +0800	[thread overview]
Message-ID: <1674049620.20111109152558@mail.ru> (raw)
In-Reply-To: <20111109032729.GA11312@gondor.apana.org.au>

> 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!

  reply	other threads:[~2011-11-09  7:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08  3:10 Add IPSec IP Range in Linux kernel Daniil Stolnikov
2011-11-08  6:24 ` Peter P Waskiewicz Jr
2011-11-08 10:51   ` Daniil Stolnikov
2011-11-08 12:08   ` Alexey Dobriyan
2011-11-08 14:24     ` Daniil Stolnikov
2011-11-08 17:16     ` David Miller
2011-11-09  1:36       ` Daniil Stolnikov
2011-11-09  1:42         ` David Miller
2011-11-09  1:54           ` Herbert Xu
2011-11-09  2:43             ` Daniil Stolnikov
2011-11-09  2:32           ` Daniil Stolnikov
2011-11-09  3:27             ` Herbert Xu
2011-11-09  7:25               ` Daniil Stolnikov [this message]
     [not found]   ` <E1RNhE5-0005rf-00.danila-st-mail-ru@f105.mail.ru>
2011-11-08 17:15     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1674049620.20111109152558@mail.ru \
    --to=danila.st@mail.ru \
    --cc=adobriyan@gmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).