I have a single Spoke (for now) that I’m testing with, I’m running Phase 2 DMVPN and I have two tunnels built on the Spoke router. Tunnel 10 goes to DC1 and Tunnel 20 goes to DC2.
The Spoke router is sitting behind a normal SoHo Linksys routers and the outside interface Gig0 – is set for IP address dhcp. DC1 -- > tunnel prefix is 10.16.1.0/23 DC2 tunnel prefix is 10.8.1.0/23.
The spoke router is a Cisco 892 – the outside interface (tunnel source) is Gig0. The inside interface is a VLAN 1 which has 8 FE ports. If I source pings to 184.108.40.206 for example from the outside interface traffic takes the default route – through the SoHo router. If I source the traffic from the VLAN 1 interface – it also takes the same route – the default route. If I connect a PC behind the router and trace to 220.127.116.11, first Hop is the VLAN interface and then all traffic is dropped. I do NAT configured with an ACL matching the inside subnet and overloading it to the outside interface of Gig0. Both Hub routers and the Spoke router are sunning EIGRP, the Spoke is obviously configured as an EIGRP Stub.
As for routing – besides EIGRP, I have three static routes configured. One – the default route 0.0.0.0 0.0.0.0 192.168.1.1 – towards the SoHo routers. The other two host based statics basically point each HUB routers public external address to the 192.168.1.1 address of the SoHo router.
Ex: IP route 18.104.22.168 255.255.255.255 192.168.1.1
Ex: IP route 22.214.171.124 255.255.255.255 192.168.1.1
Like I said if I source the traffic towards Googles pub DNS server of 126.96.36.199 from VLAN1’s interface – I get replies. If I add a host behind VLAN – I only get he gateway then traffic is dropped. Also the SoHo router is running DHCP for the inside clients (a /29).
Any help is appreciated – banging my head at this point.
1) first change the NAT/ACL to the following:
ip access-list NAT ext NAT deny ip any 10.0.0.0 0.255.255.255 permit ip 10.57.1.8 0.0.0.7 any ip nat inside source list NAT interface GigabitEthernet0 overload
2) Your QoS is very likely to be ineffective. It will only protect the voice-trafic when the link to the DSL-router is congested.