More work securing the network. I was setting up RADIUS authentication and authorization using the Network Policy Server role of Windows 2008 R2 (that will be another post). Here is a simplified network diagram.
Everything worked perfectly for the local router (rtr01) and switch (sw01) so it was time to do the same on the remote devices. I started with the switch (sw02) and then moved onto the router (rtr02) when I ran into problems. I couldn’t log into the router. I tried the router’s local username which did work indicating the router couldn’t authenticate against the RADIUS server. This seemed very odd to me since the switch, which is further away, worked perfectly. I tried a simple ping to the server and it failed. Now I was really confused, because the switch could ping the server but the router couldn’t.
At this point I’m thinking it’s some strange configuration setting on the router so I fire up Google and start searching. I come across the Cisco Extended Ping and Traceroute commands as well as a short statement indicating the originating address is the IP of the interface the packet leaves. So I try an Extended Traceroute using an originating address of 188.8.131.52 and it works. This means that a reverse route from the server to the 172.16.19.52/30 subnet doesn’t exist. Adding the following route to sw01 fixed the problem:
ip route 172.16.19.52 255.255.255.252 184.108.40.206
Switch sw01 already had a route to the 220.127.116.11/25 network. Until now there was never a need to know how to get to the WAN interfaces of the routers.