EIGRP neighbours not forming over DMVPN tunnel

[BVC]

A few weeks ago I managed to get the DMVPN tunnel to work with dialer interfaces over an ISND 30 link. But after messing around with an EIGRP distribution list and the router config I can't get the routers to form an EIGRP relationship over the tunnel interface and I have no idea why. 

When I take the passive interface off the dialer interfaces the two routers can form a relationship via the dialer interface, but when I make both dialer interfaces passive on both routers the EIGRP connection drops and doesn't form over the tunnel. I need the EIGRP to go over the tunnel so data will be encrypted with the encryption profile. 

I ran the debug EIGRP packets command on the spoke to see what happening and it keeps giving the same messages, I've attached the log. These debug messages are the same on the hub side except there is no (NULL) text in the line. 

Any help will be greatly appreciated as I have no idea what to do. 

[Rob Ingram]

Is the DMVPN tunnel even up? Provide the output of "show dmvpn" and "show crypto ipsec sa"

Why is the tunnel source as 10.1.1.1 on the hub and not dialer7?

Also don't advertise the underlayer network 11.0.0.0 in eigrp

[BVC]

I will perform the show commands when I'm back in the office tomorrow.

The tunnel source is the loopback address as the hub router as multiple dialer interfaces so I thought I could use a loopback address so every spoke router could connect to the DMVPN hub router.

Why shouldn't I advertise the 11.0.0.0 network?

[Rob Ingram]

Because the 11.0.0.0 network is your dialer interface network and if you redistribute that via EIGRP to the other router it will attempt to route to that network via the tunnel interface when it needs to be routed via the dialer interface.

You could only use a loopback if the peer routers can route to that loopback interface ip address outside of the tunnel, if you can fine.

[BVC]

Don't I want to the spoke router to route all data (even the 11.0.0.0 address) via the tunnel so all data is encrypted?

With the loopback, I currently have a static route on the spoke that points to the hub's loopback address via the tunnel, could I enable EIGRP on the loopback so the spoke routers will learn it dynamically and can still route to it via the tunnel interface.

[Rob Ingram]

Is this just lab network or are you simulating a design for production environment?

No you wouldn't advertise the 11.0.0.0 network, that's the transit network, over which the tunnel is established. Any communication between those networks (i.e. the VPN tunnel) is encrypted. You would just advertise the data/LAN networks. If you advertise the 11.0.0.0 over the tunnel you'll get issues.

[BVC]

Ah okay I understand what you mean about advertising the 11.0.0.0 address.

This is currently on a lab/test setup.

[BVC]

Hi Rob,

I've managed to get the DMVPN to work, I don't really know how but I just wiped the config from the spoke router and applied it again. The spoke router is learning all its routes via the tunnel now. I've attached both configs. 

The hub router still has the network 11.0.0.0 command and will have to since this DMVPN config will need to be put onto another router that will have spoke routers not using DMVPN and requires the network 11.0.0.0 command so it can send EIGRP messages out of the dialer interfaces. Will this cause any trouble for the DMVPN routers ? I've included the spoke's routing table in the text file and that shows there's no recursive routing error since its not learning about any of the 11.0.0.0 addresses via the tunnel. 

Another question I have is about the encryption and authentication methods, currently it has 3DES and MD5 hash and from my understanding these are very weak. Would upgrading to AES 256 and SHA 256 be sufficient enough? 

[Rob Ingram]

In your lab topology the 11.0.0.0. network is directly connected to the hub and spoke router right? So therefore the eigrp route for that network is irrelevant. In a real life topology you wouldn't advertise this network, you rely on the default route or a static route to communicate with the hub and spoke router's external/outside interface in order to establish the VPN tunnel.

Yes, 3DES/MD5 is weak. AES256/SHA256 is acceptable, however if you require the latest Next Gen algorithms you would need to use IKEv2.

Reference

https://tools.cisco.com/security/center/resources/next_generation_cryptography

[BVC]

I will look into the next gen algorithms, thanks.

The 11.0.0.0 is directly attached to both the hub and spoke network yes, but this hub router will have other routers connected to it that won't be using DMVPN or any sort of tunnelling, this means EIGRP will need to be enabled for the 11.0.0.0 network so the hub can form EIGRP neighbours with the none DMVPN routers. If I'm correct with this, this should not cause any problems with the DMVPN routers since the distribution list on the spoke router will block the 11.0.0.0 advertisements from the hub router?