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. :

# Security policies
spdadd any
-P out ipsec

spdadd any
-P in ipsec

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?


On Tue, Jun 24, 2014 at 11:08 AM, Timo Teras <timo.teras@iki.fi> wrote:
On Tue, 24 Jun 2014 10:50:15 +0500
masoom alam <masoom.alam@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 in our ipsec conf which means from any ip to any ip
> on the GRE, we want a tunnel?
> spdflush;
> spdadd gre -P out ipsec esp/transport//require;
> spdadd gre -P in ipsec esp/transport//require;
> Please help me in understanding.

These are separate from phase1 and phase2. Basically there are three

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.