01-07-2013 11:42 AM - edited 03-04-2019 06:36 PM
Hi all, I have a router that terminates VPN connections for remote access users for a particular office. This router also builds an EIGRP tunnel(s) to the DMVPN head-end routers at the data center and thats how it communicates with the rest of the corporation.
Router has a local VPN pool of IP addresses that it assigns to the remote access users upon authentication. Problem I am having is that when the users VPN into the router, they can only access local resources. They can't access anything anywhere else in the company.
VPN pool is 192.168.23.1 to 192.168.23.199
Below is the EIGRP section of the router
!
router eigrp 1
redistribute static route-map STATIC-TO-EIGRP
passive-interface default
no passive-interface Tunnel0
no passive-interface Tunnel1
network 10.10.200.0 0.0.0.255
network 10.10.201.0 0.0.0.255
network 172.23.0.0
network 192.168.23.0
network 192.168.155.23 0.0.0.0
no auto-summary
!
ip access-list standard STATIC-TO-EIGRP
permit 192.168.23.0 0.0.0.255
!
For some reason, this router does not advertise 192.168.23.0 to the DMVPN head-end router. Is it because 192.168.23.0 does not belong to any interfaces on this router? If so, is there a way I can get this to work?
Please advise
Solved! Go to Solution.
01-07-2013 11:58 AM
In the original post you ask if it is a problem because the addresses of the pool are not associated with an interface. That might have been a problem. But your EIGRP is redistributing static routes. And the route map that controls the redistribution does permit the network that covers the address pool. So assuming that there is a static route for the 192.168.23.0 network then EIGRP could advertise that network. The suggestion from Edison is that the redistribution of static routes is not working because you do not specify a default metric for the redistribution. And in EIGRP the redistribution will not work without a default metric being specified. So Edison's suggestion is to add a default metric and then perhaps the redistribution will work.
If you do add the default metric and the redistribution still does not work then I would suggest that you do a show ip route and see if the static route for the 192.168.23.0 network is in the routing table. If it is not in the routing table then this is why the redistribution is not working and you need to work out that problem.
HTH
Rick
01-07-2013 12:54 PM
Ricky
Probably the most easy thing would be to point the static route to null 0. This would make the static route valid and it would be inserted into the routing table. This would then allow the static route to be redistributed into EIGRP. EIGRP would advertise the entire network to the rest of your network and traffic for any address in that network would be routed back to your router with the VPN pool. If the traffic were for an active VPN user the traffic would be forwarded to the user and all traffic for addresses not currently active in VPN would be discarded. Probably this is the behavior that you want.
I have also seen this kind of thing done a bit differently. You could configure a loopback interface and give it the 192.168.23.0/24 address. Then EIGRP would advertise it and you would not need to worry about redistribution into EIGRP.
HTH
Rick
01-07-2013 11:44 AM
You are missing the metrics. You can use 1 1 1 1 1
Regards,
Edison
01-07-2013 11:48 AM
Hi Edison, can you elaborate please?
01-07-2013 11:56 AM
On the redistribute static command, you must also include metrics. These numbers can be arbitrary and 1 1 1 1 1 could be used as values.
You do have a static route configured for the 23.0 subnet, right?
01-07-2013 12:00 PM
Actually I don't have a static route on this router for that network. I was wandering about that also since it was setup by the engineer before my time. What would I point the static route to though since it's not assigned to any interfaces on the router.
01-07-2013 11:58 AM
In the original post you ask if it is a problem because the addresses of the pool are not associated with an interface. That might have been a problem. But your EIGRP is redistributing static routes. And the route map that controls the redistribution does permit the network that covers the address pool. So assuming that there is a static route for the 192.168.23.0 network then EIGRP could advertise that network. The suggestion from Edison is that the redistribution of static routes is not working because you do not specify a default metric for the redistribution. And in EIGRP the redistribution will not work without a default metric being specified. So Edison's suggestion is to add a default metric and then perhaps the redistribution will work.
If you do add the default metric and the redistribution still does not work then I would suggest that you do a show ip route and see if the static route for the 192.168.23.0 network is in the routing table. If it is not in the routing table then this is why the redistribution is not working and you need to work out that problem.
HTH
Rick
01-07-2013 12:11 PM
Thanks for the info Rick. That explains a lot. However I am still wandering what the static route should point to for network 192.168.23.0 since it's just a local VPN pool?
Ricky
01-07-2013 12:54 PM
Ricky
Probably the most easy thing would be to point the static route to null 0. This would make the static route valid and it would be inserted into the routing table. This would then allow the static route to be redistributed into EIGRP. EIGRP would advertise the entire network to the rest of your network and traffic for any address in that network would be routed back to your router with the VPN pool. If the traffic were for an active VPN user the traffic would be forwarded to the user and all traffic for addresses not currently active in VPN would be discarded. Probably this is the behavior that you want.
I have also seen this kind of thing done a bit differently. You could configure a loopback interface and give it the 192.168.23.0/24 address. Then EIGRP would advertise it and you would not need to worry about redistribution into EIGRP.
HTH
Rick
01-07-2013 01:38 PM
Thanks! It's working now. Funny what Null0 can do
Much appreciated!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide