Re: [opennhrp-devel] NHRP Protocol Error - Cisco HUB

[Timo T. <tim...@ik...>]

Burrows, Zack wrote:
> Let's go with "or something really funny is happening".  After a few
> days of working this issue out we were able to trace it to the ip_gre
> kernel module.  We had applied a patch from the OpenWRT folks that
> enabled GRE interfaces to be added to a bridge.  This patch was
> somehow applying a bogus IP header to the NHRP packet.  This bogus IP
> header and NHRP packet was them being encapsulated in IP/GRE and
> being sent out.  The remote end was having a hard time handling this
> packet (duh!)...

Ah, good that you found the problem.

> I have a few questions/comments:
> 
> Under KERNEL REQUIREMENTS in the readme it says to enable ARPD
> (CONFIG_ARPD).  What is the reasoning for this?  I ask because the
> description for this flag says "don't use, if you do you need arpd,
> etc..."

Netlink ARPD API is the way opennhrp talks with kernel about the
public IP-private IP mappings. Without that option you won't
have working opennhrp. The kernel help texts for that option
were outdated and have been update some time ago. See:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e61a4b634a15c11725eac8e66b457ba411168c7f;hp=125bb8f5637bd653244728f734bcac218986d910

> The readme also suggests that the latest alpha version of ipsec-tools
> should work (CVS or 0.8 snapshot).  This is not a good idea because
> alpha20090903 (latest) is broken in regards to Phase2 SA and GRE.
> During Phase2 ipsec-tools includes a port value with the proposal,
> the 500 should be a 0 (see below).  Using the exact some
> configuration files alpha20090126 works as expected. (I am in the
> process of testing alpha20090422 and aplha20090820).

Ok. Sounds like a bug which needs fixing.

> *Aug  8 08:56:17.903: IPSEC(validate_proposal_request): proposal part
> #1 *Aug  8 08:56:17.903: IPSEC(validate_proposal_request): proposal
> part #1, (key eng. msg.) INBOUND local= x.y.z.212, remote= x.y.z.207,
>  local_proxy= x.y.z.212/255.255.255.255/47/500 (type=1), 
> remote_proxy= x.y.z.207/255.255.255.255/47/500 (type=1), protocol=
> ESP, transform= NONE  (Transport), lifedur= 0s and 0kb, spi= 0x0(0),
> conn_id= 0, keysize= 0, flags= 0x0
> 
> 
> In regards to using Cisco tools to help diagnose this, HA!  The debug
> commands suggested are the ones I had been using to get the info I
> was submitting.  Anything having to do with debug nhrp was useless
> because the packet was invalid (hence the 2 ERROR messages).  The
> 'monitor capture' method did not help either, the packet that was
> captured was the IPSEC packet (using 'process-switched' capture
> point).  Cisco wisdom prevails here... In order to do captures on a
> tunnel interface you need to use a 'cef' capture point. DMVPN is not
> compatible with 'cef' and actually needs to be disabled for DMVPN to
> work...

Uh. Ok. Thanks for the info on this.

> Thanks for the help and suggestions, I'll follow up with the results
> of my alphaXXXXXXXX testing.

Great. Thanks.

- Timo