02-12-2020 08:22 AM
I have a site I'm investigating and I've found they have multiple connected Cisco devices. I initially thought I was unable to telnet into their router at all, but upon further investigation, if I telnet into a connected switch, I can then successfully telnet into this router.
Site1 --(telnet)--> router 172.16.232.2 (doesn't work)
Site1 --(telnet)--> switch1 172.16.232.5 --(telnet)--> router 172.16.232.2 (does work)
I can ping the everything successfully throughout but I cannot telnet or gather SNMP data, which is my ultimate goal so I can set it up for SolarWinds NCM.
02-12-2020 08:49 AM
Hello,
what if you telnet to IP address 192.168.9.62, which apparently is the IP address of the outside facing interface ?
02-12-2020 11:09 AM
Yes, doing a telnet to this address worked without issue. This seems like it is set up differently from every other site if this is the only solution. But at least it is a way directly in.
02-12-2020 11:54 AM
Hello,
from where (which IP address) are you trying to access the router ? Is there anything in front of the router, like a firewall ?
02-12-2020 12:17 PM
Each site has a firewall on premise. Sites are on certain networks. This router in question is 172.16.232.2 and the site firewall is 172.16.232.1. From the site I'm trying to access the router, there are several networks, but the server I'm using is 172.16.101.97 and the firewall is using 172.16.101.67.
I've, I hope completed adding each piece of equipment, but this is the only odd one besides a piece of equipment the ISP requires at a site. All of them have been able to ping and access SNMP on the private IP 172.16.x.x except this router from this server. However, it appears I can access it via the 192.168.x.x address for SNMP.
02-12-2020 12:51 PM
There is perhaps another explanation for the behavior described in the original post. Perhaps this site router is configured with access-class on the vty ports. The access-class uses an access list to determine what addresses are allowed remote access and what addresses are not. If you attempt telnet directly you are coming from an address that is not permitted. But if you telnet to the switch in that site network and then telnet to the router then the telnet source address is the switch that is permitted. If you can get this
sh run | in line returned:
line con 0
line vty 0 4
line vty 5 15
then perhaps you could post the output from the command show run | begin line vty
This would allow us to see if there is an access-class configured.
02-13-2020 12:16 PM
From the Switch:
line vty 0 4
password con@@nect
login
length 0
line vty 5 15
login
!
!
end
From the Router:
line vty 0 4
exec-timeout 30 0
password con@@nect
login
!
scheduler allocate 20000 1000
ntp server 172.16.200.10
end
02-15-2020 06:56 AM
Thank you for the additional information. Clearly there is not an access-class applied to the vty. So that theory does not hold up. I am a bit puzzled about the topology of this network. You tell us that this router is connected to a firewall and that the address of the firewall is 172.16.232.1. I would expect that the default route for the router would have the firewall as its next hop. But it does not. The next hop for the default route is 192.168.9.61. I wonder if this has something to do with the problem with telnet directly to the router?
I also wonder about the possibility that the firewall has some security policy that does allow telnet responses from 192.168.9.61 but does not allow telnet response from 172.16.232.2.
02-15-2020 07:34 AM
I continue to think about this issue and read through the complete discussion again. I am struck by this statement in the original post
"I can ping the everything successfully throughout but I cannot telnet or gather SNMP data"
If ping from his source directly to the router is successful then there is successful IP connectivity and the issue would not be anything about whether the default route next hop is the firewall or something else. When some protocol (like ping) is successful and some protocol (like telnet) is not successful it certainly suggests that some device in the path has a security policy that is denying the telnet.
It is an interesting question why a security policy might allow the telnet to the switch but not allow telnet to the router. But I think it does not change the indication that there is a security policy. So where might that security policy be? The obvious suggestion is the firewall. But I am also wondering about the device at 192.168.9.61. What is this and might it have some security policy?
02-12-2020 09:28 AM - edited 02-12-2020 09:32 AM
Hello
@fuzbuster83 wrote:
I have a site I'm investigating and I've found they have multiple connected Cisco devices. I initially thought I was unable to telnet into their router at all, but upon further investigation, if I telnet into a connected switch, I can then successfully telnet into this router.
Site1 --(telnet)--> router 172.16.232.2 (doesn't work)
Site1 --(telnet)--> switch1 172.16.232.5 --(telnet)--> router 172.16.232.2 (does work)
I can ping the everything successfully throughout but I cannot telnet or gather SNMP data, which is my ultimate goal so I can set it up for SolarWinds NCM.
Sounds like you have a dynamic access-list enabled on the switch, meaning ONLY after users have authenticated with the switch can they then telnet to the routers, and this would be because after authentication a dynamic access-list would have be created to allow telnet communication to the rtr via the switch.
On the switch
sh access-lists
sh run | in line
02-12-2020 11:11 AM
sh access-lists returned nothing
sh run | in line returned:
line con 0
line vty 0 4
line vty 5 15
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