Hi Timo,
Suppose if I have one hub and two spoke nodes, each have one public address
and one NBMA address. If I specify the following configurations in the
racoon file for the HUB to Spoke1. :
spdflush;
flush;
# Security policies
spdadd 10.0.0.0/16 10.1.0.0/16 any
-P out ipsec
esp/tunnel/192.168.2.1-62.149.40.78/require;
spdadd 10.1.0.0/16 10.0.0.0/16 any
-P in ipsec
esp/tunnel/62.149.40.78-192.168.2.1/require;
Then repeat the same thing from the Spoke1 --> HUB - only switch the NBMA
addresses, will it work?
Assume the same is done between Hub and Spoke 2. If I run OpenNHRP on the
hub and spokes nodes, will dynamic tunnel between Spoke1 and Spoke2 will be
formed or not? Dynamic in the sense that we have not specified any such
configuration for Spoke1 and Spoke2 in the ipsec.conf or in the
racoon.conf. Am I missing some thing here? According to Cisco DMVPN, the
Spoke1 <---> Spoke2 ipsec tunnels will be formed dynamically.
Further, I am testing all this topology in the LAB, IF i am not using BGP
and specifying static routes in the HUB, whether Spoke1 will learn the
routes automatically and thus no routes will be needed to be specified at
the Spoke1 or Spoke 2 for traversing their private networks?
Thanks.
On Tue, Jun 24, 2014 at 11:08 AM, Timo Teras <timo.te...@iki.fi> wrote:
> On Tue, 24 Jun 2014 10:50:15 +0500
> masoom alam <masoom.a...@gmail.com> wrote:
>
> > Perhaps the following diagram can explain what I am asking....
> >
> > [image: Inline image 1]
> >
> >
> > My question is that how the dynamic&Temporary spoke-to-spoke Ipsec
> > tunnels are formed in OpenNHRP, especially in the case, where we are
> > giving 0.0.0.0/0 in our ipsec conf which means from any ip to any ip
> > on the GRE, we want a tunnel?
> > spdflush;
> > spdadd 0.0.0.0/0 0.0.0.0/0 gre -P out ipsec esp/transport//require;
> > spdadd 0.0.0.0/0 0.0.0.0/0 gre -P in ipsec esp/transport//require;
> >
> > Please help me in understanding.
>
> These are separate from phase1 and phase2. Basically there are three
> things:
>
> 1) Kernel Security POLICY. It tells kernels what packets needs to be
> IPseced and with what kind of transformation. This what spdadd does.
> They do not create any IPsec state or connection. They are comparable
> to 'ip route add' entries. Use "setkey" or "ip xfrm policy" to
> manipulate these kernel objects. (With other IKEs, e.g. strongSwan, the
> IKE can also directly manage these policy object.)
>
> 2) IPsec phase1 - is negotiated by IKE (e.g. ipsec-tools) and it's
> internal to the IKE. It handles authentication, and negotiates first
> set of encryption keys. Usually phase1 has long life-time so the same
> phase1 can be used to negotiate multiple phase2s. Kernel has no idea of
> what phase1's exist.
>
> 3) IPsec phase2 - is negoatiated by IKE and contains encryption keys
> for specific tunnel. Once negotiated these encryption keys will be
> installed to kernel. In linux you can dump these from kernel with "ip
> xfrm state show" or from ipsec-tools with "racoonctl show-sa ipsec".
>
> Now this can be confusing as there can be 'loose' mapping of IPsec
> policy and the phase1/phase2. Like in the default example, the single
> policy tells to encrypt all GRE traffic with point-to-point IPsec
> tunnels (that's what the 'transport' mode means). IKE based on that
> policy can create the node-to-node phase1s and phase2s.
>
> Hope that explains it.
>
> /Timo
>
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
opennhrp-devel mailing list
opennhrp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
