Hi Timo, 

Thanks for the answer. I have three VMs. The point is that when I make a point-to-point GRE tunnel without OpenNHRP, I get ipsec tunnel established which can be verified using TCPDUMP with the output ESP in it as follows:

15:01:38.764627 IP alam-VirtualBox.local > 195.171.2.2: ESP(spi=0x071da240,seq=0x26), length 124
15:01:38.765377 IP 195.171.2.2 > alam-VirtualBox.local: ESP(spi=0x01b38182,seq=0x20), length 124


However, When I remove point-to-point in the options of GRE  from /etc/network/interfaces and start executing OpenNHRP, the ESP thing get disappeared from the tcpDUMP.


Here is the output of the OpenNHRP:


opennhrp[2232]: OpenNHRP 0.14.1 starting
opennhrp[2232]: Interface lo: configured UP, mtu=0
opennhrp[2232]: Interface eth0: configured UP, mtu=1500
opennhrp[2232]: Interface gre0: config change, mtu=1476
opennhrp[2232]: Interface gretap0: config change, mtu=1476
opennhrp[2232]: Interface tun0: configured UP, mtu=1476
opennhrp[2232]: Filter code installed (18 opcodes)
Create link from  (192.168.1.1) to 10.255.255.1 (192.168.1.1)
opennhrp[2232]: [10.255.255.1] Peer up script failed: exitstatus 1
Create link from  (192.168.1.1) to 10.255.255.1 (192.168.1.1)
opennhrp[2232]: [10.255.255.1] Peer up script failed: exitstatus 1
Create link from  (192.168.1.1) to 10.255.255.1 (192.168.1.1)
opennhrp[2232]: [10.255.255.1] Peer up script failed: exitstatus 1
Create link from  (192.168.1.1) to 10.255.255.1 (192.168.1.1)
opennhrp[2232]: Interface gre1: config change, mtu=1476
opennhrp[2232]: Interface gre1: GRE configuration changed. Purged 1 peers.
opennhrp[2232]: Interface gre1: config change, mtu=1472
Create link from  (192.168.1.1) to 10.255.255.1 (192.168.1.1)
opennhrp[2232]: Filter code installed (20 opcodes)
opennhrp[2232]: Interface gre1: configured UP, mtu=1472
opennhrp[2232]: [10.255.255.1] Peer up script failed: exitstatus 1
Create link from 10.255.255.2 (192.168.1.1) to 10.255.255.1 (192.168.1.1)

Output of OpenNHRP at Spoke1


opennhrp[2187]: OpenNHRP 0.14.1 starting
opennhrp[2187]: Interface lo: configured UP, mtu=0
opennhrp[2187]: Interface eth0: configured UP, mtu=1500
opennhrp[2187]: Filter code installed (18 opcodes)
Create link from  (195.171.2.2) to 10.255.255.2 (192.168.1.1)
VPN connexion established
Phase 2 established : 195.171.2.2[500] -> 192.168.1.1[500]
opennhrp[2187]: Unknown NLmsg: 0x00000002, len 64


OpenNHRP at Spoke2


opennhrp[2222]: OpenNHRP 0.14.1 starting
opennhrp[2222]: Interface lo: configured UP, mtu=0
opennhrp[2222]: Interface eth0: configured UP, mtu=1500
opennhrp[2222]: Filter code installed (18 opcodes)
Create link from  (198.174.3.3) to 10.255.255.3 (192.168.1.1)
Phase 2 established : 198.174.3.3[500] -> 192.168.1.1[500]
opennhrp[2222]: Unknown NLmsg: 0x00000002, len 64


Please guide. 



On Thu, Jun 26, 2014 at 10:19 AM, Timo Teras <timo.teras@iki.fi> wrote:
On Thu, 26 Jun 2014 08:18:12 +0500
masoom alam <masoom.alam@gmail.com> wrote:

> Suppose if I have one hub and two spoke nodes, each have one public
> address and one NBMA address. If I specify the following

In NHRP terminology:
NBMA = non-broadcast = public Internet address.
protocol address = private address.

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

No. This incompatible. Tunnel policy is different from transport policy
on the wire. You will also lose the ability create dynamic tunnels
unless you hack opennhrp-script to adjust SPD on spoke discovery.
Though, tunnel mode makes nhrp pretty useless because the NBMA address
is selected by security policy instead of by NHRP.

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

No. Tunnel mode and BGP are incompatible.

Your suggestion is IPsec tunnel - not DMVPN.

- Timo