cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6139
Views
5
Helpful
10
Replies

Can Ping But Not Telnet

fuzbuster83
Level 1
Level 1

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.

10 Replies 10

Hello,

 

what if you telnet to IP address 192.168.9.62, which apparently is the IP address of the outside facing interface ?

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.

Hello,

 

from where (which IP address) are you trying to access the router ? Is there anything in front of the router, like a firewall ?

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.

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. 

HTH

Rick

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

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.

HTH

Rick

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?

HTH

Rick

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

 

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

sh access-lists returned nothing

sh run | in line returned:

line con 0
line vty 0 4
line vty 5 15

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco