Can ping ... cannot Telnet

[superduperlopez]

Hello I hope you can help......

I am having the following problem....

I cannot telnet to the interface that connects to the Internet on a 2800 series router at a customer's site. I can ping the interface OK and the client does not have any problems connecting to the Internet, however I cannot telnet this interface (int Dialer1 with public IP address)

I can, however, create a VPN connection to one of client's PC at the client's office and then telnet to the FA interface of the router from the customer's PC.

Any help welcome....configuration attached....I did not configure this router in the first place but I am now trying to solve this problem......no much luck so far...

[superduperlopez]

Please find the configuration I'm using attached to this reply......for some reason I couldn't attach it to my original post.....

[Richard Burts]

I am looking at the configuration that you posted. Am I correct in assuming that this is the router to which you can ping but not telnet?

I see that the vty are configured with access-class. Even though it looks like the access list should permit telnet I would suggest as an experiment that you remove access-class from the vty and see if the behavior changes.

Also can you tell us where in the network (and from what addresses) you are trying to ping and telnet? It might help identify where in the config to concentrate our search.

HTH

Rick

[superduperlopez]

Yes this is the router to which I am trying to telnet into.....

I am trying to telnet from my work offices into the client's router which has an 82.X.X.X address

The ping works fine (to the Dialer1 interface), I get 4 replies (0% loss) everytime....but cannot telnet

As I already said, strangely enough, telnet is possible to the FA0/0 interface from the customer's LAN PC (I connect to the client's PC through a VPN)

cheers

[superduperlopez]

sorry.........also forgot to mention that we have many other clients through the country and we have no problems telnetting to the other routers.

[pkhatri]

Does the router log show any denied telnet attempts or something to that effect ?

Paresh

[Richard Burts]

Am I correct to understand that you ping to the dialer interface and the ping succeeds but you attempt to telnet to the dialer interface and it fails?

Could you help us understand what happens when you attempt to telnet? Do you get a prompt for username? Does the telnet attempt just hang? Or what happens?

HTH

Rick

[superduperlopez]

yes, that's right, I can ping the dialer successfully but when attempt to telnet to the dialer interface it fails with the message below:

Could not open connection to the host, on port 23:

Connect failed

The router is running IOS version 12.3(8)T5

should I try upgrading the IOS??

also, when I do a sh users..........there is only one line being used........

cheers

[Richard Burts]

I would be surprised if changing IOS solved the problem. But it might be something to try - certainly would not hurt to try a different IOS.

Knowing that the connect attempt fails is helpful. I will continue to look at your config and look for the cause.

HTH

Rick

[superduperlopez]

Hi Rick, thank you for your help so far.

I've been struggling with this all day ...again :((

I've tried the following....

First I tried adding the access-list 199 (inbound) to the rest of the vty lines 5 to 15......but this didn't do anything...

Then I completely removed the access-list 199 (as it allows all ip traffic anyway) from all vty lines and the dialer1 interface...but still couldn't telnet

As I said I didn't build the configuration in the first place...and having been looking further into it I found the following strange...

1) why did they put an ip address on the fa 0/0 interface to then use sub-interfaces??

2) the following line on access-list 100 does not seem to make any sense?? does it intend to stop all broad casting??? to me it simply stops host 255.255.255.255 (!!!!!!) to access anywhere

access-list 100 deny ip host 255.255.255.255 any

also, why are they using

access-list 100 deny ip 127.0.0.0 0.255.255.255 any

3) all the other access-lists seem to refer to hosts 192.168.96.1 and 192.168.96.3.........

However, these ip addresses are not used anywhere else in the configuration?? (none of the interfaces relate to either of these addresses)

4) if you take any of the access-lists i.e. below

access-list 101 permit ip 192.168.101.0 0.0.0.255 host 192.168.96.1

access-list 101 permit ip 192.168.101.0 0.0.0.255 host 192.168.96.3

access-list 101 deny ip 192.168.101.0 0.0.0.255 192.168.0.0 0.0.255.255

access-list 101 permit ip 192.168.101.0 0.0.0.255 any

aren't lines 3 & 4 redundant??

They seem to be denying traffic from inside the LAN to anywhere else in the LAN (besides 96.1 and 96.3 that is)

and then in the 4th line allowing that same source traffic to go anywhere ..........is this for access to the Internet????

5) Finally, why is he including access-list 100 on the "route-map nat permit 10"

sorry about all these questions........this is my first job in the networking industry after becoming CCNA qualified last July and although I am currently preparing for the CCNP some of the stuff in this configuration seems to be beyond my scope....so any help would be highly appreciated......I have kind of been given the configuration to sort it out but some of the lines just do not make sense .....

Again, thank you......

[Richard Burts]

I will provide some answers to the questions that you ask and then I have a couple of comments.

1) I am not sure why they put an IP address on fa0/0 and then use subinterfaces. I wonder if the address was part of an early config (before connection to a switch with VLANs). At any rate it does no harm.

2)deny ip host 255.255.255.255 any is a way to do a sanity check on traffic. It is checking for packets with a source address of the broadcast address - which is not legitimate traffic and the access list is making sure that it does not get through. It would be broadcast traffic if the address were the destination address, but here it is the source address.

Similarly the address 127.0.0.0 is a way of representing the local loopback and is not a legitimate source address and the access list is filtering it out.

3) I agree that these addresses are somewhat odd. They show up in the access lists which are used for address translation and are used in the class maps used for traffic shaping. And they are in the subnet used on the fa0/0 interface.

4) I do not think that lines 3 and 4 are redundant. If we look at the functionality of each line there is a logic as to why it is there, and that it does not become redundant with any other line in the access list. lines 1 and 2 permit traffic from a specific subnet (192.168.101.0) to two specific hosts. line 3 says that any traffic from that subnet to network that start with 192.168 is to be denied. Line 4 says that traffic from that source subnet to anywhere else is to be permitted.

5) the route-map nat permit 10 gives a string of access lists which identify traffic that is to be translated.

My comments include:

- I find the use of access list 199 as both inbound access-group on the dialer interface and as access-class on the vty ports to be unusual. Partly it is unusual to have the same list on an interface and on the vty. Also the normal practice for access lists in access-class is to use standard access lists not extended access lists. I suggest that you remove access-group 199 from the dialer interface and remove access-class 199 from the vty ports. After you get this working you can think about whether to put some access lists back.

- I see that the address on the dialer is negotiated. I want to verify that this is the address that you are using for ping and for telnet.

- I would like to verify that you are really getting to the right box: can you do traceroute to the address and verify that the path that it shows is going to the right box?

Also could you turn on debug ip icmp, then do a ping to the address and verify from the debug output that your ping actually got to this router?

HTH

Rick

[superduperlopez]

Hi Rick, again, thank you so much for your help...it is helping me a lot understanding the system...

I have one more question regarding point 5, the route-map nat...

as you said it check the access-list to see what traffic is to be translated. However, last line of access-list 100 is permit ip any any ...as per below

access-list 100 remark SDM_ACL Category=3

access-list 100 deny ip host 255.255.255.255 any

access-list 100 deny ip 127.0.0.0 0.255.255.255 any

access-list 100 permit ip any any

so...won't this make all the other access-lists redundant. I mean, if understanding right, the first access-list the route-map will look at is the access-list 100....reach the last line, see that all the traffic is permitted (besides the 2 denies just before) and not even touch the rest of the access-list???

Regarding your comments....

I had already removed access list 199 from the vty lines and the dialer interface as they were allowing all the ip traffic anyway I did not see the point on having them there anyway.......

You are rigth the ip adderss on the dialer interface is negotiated and yes this is the address I am ping in into and trying to telnet to

I am trying to ping the ip address that shows up next to the Dialer1 interface when I do a sh ip int brief.....this should be the correct ip address to use no??

I've done the tracert to that ip adderss from the pc on my office....it is only 3 hops away.....ending on the correct adderss which belongs to Zen internet which is the provider they are using according to the configuration. It also says that it is a DSL line which is correct.

I did also turn on the debug ip icmp, however, although I get a 0% loss on my prompt command NOTHING happens in the router

As I have already told you I can telnet through the LAN so I turned on debuging for telnet too and established a telnet connection through the LAN...again although I did actually connected to the router, the router did not show any signs through the debugging in the Terminal session.........

So then I tried again with the debug ICMP but this time pinging to the FA0/0 interface (192.168.96.2) and the same happened.........all pings are successful but nothing shows up on the Terminal session........

well, that's all for now........again, can't thank you enough.....it is so nice to actually be able to speak to some about all this.....

[Richard Burts]

If the traceroute seems to be going correctly that is a good sign.

As for the debug producing no output in the terminal session, did you do a terminal monitor in the terminal session before you tried ping and traceroute. There might also be a possibility that the router is configured to suppress the debug output. If you would post the first dozen or so lines of the output of show logging, it should show how all the logging destinations are set up and that might be helpful.

HTH

Rick

[Richard Burts]

Having read the messages in this discussion again I have another thought. In the original post you state that you can successfully telnet to the router from PCs on the inside of the network but can not telnet to the dialer. This suggests that the failed telnet is coming through the Internet to the router. It makes me wonder whether there is some kind of firewall that you are going through that will allow ping to pass through but that is denying telnet.

HTH

Rick

[superduperlopez]

Hi Rick, I thought about that too....

But there is no firewall in the customer's site and although there is one in our side, we can telnet to many other customers no problem........

thank you