Telnet access to the CLI of my remote UC520 via Internet

Answered Question
Feb 5th, 2009

I want to access the CLI over the Internet of my UC520.

Internally I can telnet ot the CLI using Hyperterminal to the default address and port, 192.168.10.1 23

I set up a telnet password and even set up a static nat to between by static public ip and the above address:port. But still no luck.

What am I missing?

!
ip http server
ip http authentication local
ip http secure-server
ip http path flash:
ip nat inside source list 1 interface FastEthernet0/0 overload
ip nat inside source static tcp 192.168.10.1 23 interface FastEthernet0/0 23
!

Thanks!

I have this problem too.
0 votes
Correct Answer by Marcos Hernandez about 7 years 10 months ago

I see. In that case, what you need to do is edit the Access List on the WAN interface to allow for Telnet inbound. Typically this access list is 104.

Do the following:

1) show run int fast 0/0

To get the output of the configuration for the WAN interface. Identify the ACL number (ip access-group XXX in)

2) Then do "show access-list XXX"

3) You will get an output with sequence numbers. This is the order in which the entries are read and the ACL enforced. You will need to insert your "permit" for telnet in the list.

4) You can put is at the top of the list with something like:

conf t

ip access-list extended XXX

5 permit tcp any any eq 23

5) Type "exit" and "wr mem" to save.

It is usually better to use SSH to connect from the WAN, it is more secure. Isn't this an option? Also, it is always a good idea to enable the VPN server on the UC500 so you can connect remotely and run CCA (that way you don't have to wait to be on site).

Thanks,

Marcos

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Marcos Hernandez Thu, 02/05/2009 - 14:55

Have you tried doing this through CCA? There is an ACL on the WAN interface that needs to be modified too, and CCA autmatically configures this.

Marcos

mcastrigno Thu, 02/05/2009 - 15:08

Hello Marcos. Thanks for your reply.

Yes the CCA has a check box to configure or allow telent access. I checked that box also.

What needs to modified on the WAN interface?

What would I see for the that when I do I "show run" on the CLI?

Thanks.

Marcos Hernandez Thu, 02/05/2009 - 15:18

I meant the port forwarding section in the Firewall tab. Try to configure the port forwarding there (but first delete that nat statement that you added). Let me know,

Marcos

mcastrigno Thu, 02/05/2009 - 15:32

Thanks Marcos.

I am not at that site until Tuesday next week but let you know how it works.

The nat I added was through CCA - I just like to check the resulting configuration with "show run" at the CLI.

Thanks!

Correct Answer
Marcos Hernandez Thu, 02/05/2009 - 15:41

I see. In that case, what you need to do is edit the Access List on the WAN interface to allow for Telnet inbound. Typically this access list is 104.

Do the following:

1) show run int fast 0/0

To get the output of the configuration for the WAN interface. Identify the ACL number (ip access-group XXX in)

2) Then do "show access-list XXX"

3) You will get an output with sequence numbers. This is the order in which the entries are read and the ACL enforced. You will need to insert your "permit" for telnet in the list.

4) You can put is at the top of the list with something like:

conf t

ip access-list extended XXX

5 permit tcp any any eq 23

5) Type "exit" and "wr mem" to save.

It is usually better to use SSH to connect from the WAN, it is more secure. Isn't this an option? Also, it is always a good idea to enable the VPN server on the UC500 so you can connect remotely and run CCA (that way you don't have to wait to be on site).

Thanks,

Marcos

mcastrigno Thu, 02/05/2009 - 16:00

Thanks Macros.  You answered another question I was wonder about ... accessing remotely with CCA.

I will do all this when I get on site again.

I am not all that familar with SSH. What does one need from the client side to access this way instead of telnet.

Thanks again , I will let you know how it all works out.

Marcos Hernandez Thu, 02/05/2009 - 16:16

You can use PUTTY (just Google it). It offers a GUI based SSH client. Just enter the target IP and that's it.

Good luck,

Marcos

mcastrigno Tue, 02/10/2009 - 13:21

Marcos,

Setting ACL in the CLI for the wan port as you described worked like a champ. Thanks!

I am also trying to get a handle on what CCA can and cannot do. I cannot find in CCA where I could have accomplished the same thing.

In a prevoius reply you mention "I meant the port forwarding section in the Firewall tab." Where is the "Firewall tab" in CCA you refer to? Do you mean the dialog box you get when you select Configure->Security->Firewall and DMZ?? In here I see no "port fowarding section.

Can you help me understand the corelation between what I should see in CCA after modifying the ACL in the CLI?

Thanks

Marcos Hernandez Tue, 02/10/2009 - 19:14

I am sorry, but I meant "Security ---> NAT" which I think is what you did. I will try to recreate locally, but this should have created a pinhole throug the WAN ACL.

Thanks,

Marcos

relionllc Thu, 02/05/2009 - 19:26

It may be a lot easier just to VPN in and then you should be able to use CLI or CCA with that private IP.

pzimmer1230 Wed, 07/15/2009 - 19:53

I am have a very interesting issue.  I simply want to open Telnet/SSH access to the outside interface of my 520 (Fa0/0).  The interesting part of our problem is that when we completely remove the access-group 104 in policy on the outside interface it does NOT allow us to connect via telnet.  We have the same issue when we add an permit policy to the access-list 104 and apply it as an in policy on Fa0/0.  Telnet from all internal interfaces works just fine.

Is there some hidden policy applied to Fa0/0 when no access-group is explicately configured?

interface FastEthernet0/0

description $FW_OUTSIDE$

ip address 67.x.x.x 255.255.255.248

ip nat outside

ip inspect SDM_LOW out

ip virtual-reassembly

duplex auto

speed auto

crypto map corp

!

line vty 0 4

exec-timeout 120 0

privilege level 15

password ***********

transport preferred telnet

transport input all

transport output all

!

access-list 104 remark auto generated by SDM firewall configuration

access-list 104 remark SDM_ACL Category=1

access-list 104 permit ip any any eq telnet

access-list 104 permit udp any eq bootps any eq bootpc

access-list 104 permit icmp any any echo-reply

access-list 104 permit icmp any any time-exceeded

access-list 104 permit icmp any any unreachable

access-list 104 permit ip any any

access-list 104 deny   ip 10.1.10.0 0.0.0.3 any

access-list 104 deny   ip 192.168.10.0 0.0.0.255 any

access-list 104 deny   ip 10.1.1.0 0.0.0.255 any

access-list 104 deny   ip 10.0.0.0 0.255.255.255 any

access-list 104 deny   ip 172.16.0.0 0.15.255.255 any

access-list 104 deny   ip 192.168.0.0 0.0.255.255 any

access-list 104 deny   ip 127.0.0.0 0.255.255.255 any

access-list 104 deny   ip host 255.255.255.255 any

access-list 104 deny   ip any any

access-list 104 deny   ip 192.168.16.0 0.0.0.255 any

relionllc Wed, 07/15/2009 - 20:16

That's very odd. No access-list should leave it wide open for telnet. I even tried it on mine just to see. This may sound bad, but are you sure? Nobody will ever tell you this, but I ran into a few weird problems here and there and would you believe the resolution was to do a reload on the router? Don't forget to save your config first.

Also, could you clarify, you say the same happens when you add the permit policy- exactly what are you adding and where? If you're not talking about the 8th line in your ACL, I'd point out that all of your deny statements are worthless if you have that permit any any up higher like that, especially that last one, "access-list 104 deny   ip 192.168.16.0 0.0.0.255 any." And last, you don't have a permit statement for your SSH, 22.

pzimmer1230 Wed, 07/15/2009 - 20:34

No offense taken... I removed the 'access-group 104 in' multiple times all with the same result.  I see the packet come in on the interface when I do a debug ip packet (source address) so I know it is hitting the FA0/0 interface.  I haven't tried reboot it with the access-group removed from the interface, wonder if there is some sort of bug in 12.4(20)????

Your point about the sequence of the ACL is spot on and I appreciate the feedback.  If the reboot doesn't fix the issue I will try to figure out what is preventing the UC from processes the request through debugging (any suggestions?), worst case I'll call TAC see what they think.  Thanks for the help.

Marcos Hernandez Thu, 07/16/2009 - 05:44

What happens if you remove the "ip inspect" command under the WAN interface? Also, is the UC500 connected to a firewall on its WAN?

Thanks,


Marcos

pzimmer1230 Thu, 07/16/2009 - 07:59

Thanks for the reply......We get the same result when we take off the 'ip inspect' policy.  There is a CPE device from the carrier on FA0/0 (We do not believe it is performing any filtering or firewall services).  To verify our assumption, we took the ethernet cable off of the CPE, re-addressed an interface on our laptop and connected directly to FA0/0.  We are able to ping the WAN IP address on FA0/0 when we are connected directly it but still cannot telnet to the IP address on the Interface.  Based on these results I think we eliminated the carrier equipment from being a suspect in this investigation.  It is the strangest thing, there is no access-list applied to the interface and no NAT outside,inside policies so I have no idea why the interface won't accept incoming telnet sessions.  We are going to try saving the configuration, reloading the device to factory defaults and loading our configuration back in.  Why does everything have to be soo darn difficult?

relionllc Thu, 07/16/2009 - 08:39

I am guessing you don't need to go to the extent of going back to defaults, I would definitely try just a plain "wr" then "reload." Ten minutes and I'll bet your mystery bug goes away.

pzimmer1230 Thu, 07/16/2009 - 18:31

Thanks everyone for your responses.  I figured out what was going on...We applied an extended ACL to the outside interface, saw the traffic was hitting the ACL, applied another ACL on the VTY connections, saw the traffic was hitting ACL, found a NAT policy CCA created that NAT'd the outside network to the outside interface (how that makes sense I have no idea)....We took the outside network out of the ACL used for the NAT policy and viola everything started working.  I have no idea why CCA thought it needed to NAT an outside (non-RFC1918) address block but it did.  So everything was working on the inbound path but was getting resequenced via the NAT policy on the outbound leg.  Just goes to show you have to also look at both inbound and outbound legs of a data path.  Thanks again for all of the responses.

Marcos Hernandez Thu, 07/16/2009 - 19:59

Glad yo hear you solved the mystery. I would be interested to see the actual NAT CLI command that you say CCA put there. This sounds very weird.

Thanks,


Marcos

Actions

This Discussion

Related Content