Hi,
Ok understood, in that case ipsec encapsulates it and provides the tunnel
to reach the endpoint that lives (in my case) behind nat and as you say,
as I'm only stating the public address to be resolved in the nhrp section,
so I can imagine then it could get confused and possibly drop the packet.
I don't even think its getting to the point of getting confused so far
though. Ideally I need to look at the encrypted traffic to see if there is
any nhrp being sent down it. Also I'm not seeing anything in the debug
logs on either side to give me some hits into why its failing?
I'll have another bash at this tonight.
Cheers!
Jon.
On Tue, 1 Aug 2017 at 06:24 Timo Teras <timo.te...@iki.fi> wrote:
> On Mon, 31 Jul 2017 19:27:41 +0000
> "M87tech [Jon]" <m87t...@gmail.com> wrote:
>
> > Out of interest, what address will nhrp bind to and source its
> > messages from? I'm assuming it binds to the gre tunnel address? If
> > so I'm still not seeing any packets being sent from the gre tunnel?
>
> NHRP works directly on top of layer 2, so there's no addresses to bind
> to. The protocol number is 0x2001.
>
> > does it matter that both ends are behind NAT? I thought transport
> > mode allowed this.?
>
> It might confuse nhrpd. All spokes can be behind NAT. But the hub nodes
> by design should not be behind NAT.
>
> Timo
>
--
M87 TECH
Jon Clayton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
opennhrp-devel mailing list
opennhrp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
