Most routers can redirect from one port on the outside to another port on the inside. The configuration should be pretty obvious, so if it isn't you may have to look it up on your particular router. To change it on the cisco, you would have to use the rotary command under "line VT 0 4". I am pretty sure this will not disable the original telnet port, but will allow you to also telnet to it on port 3000 + the rotary number. See example below.
Like the other poster said, make sure your Cisco router has access to the internet first (check the basics). If it does not have a default route, it cannot return the telnet traffic to the outside telnet client.
line VT 0 4
This would make your router listen also on port 3033.
I have the same setup with SSH, I'll list what I did and what I'd recommend to avoid problems.
- Security first, set up SSH if possible. Set up a static IP address on the interface of your access server that's within the same network range of your linksys router. This is most likely 192.168.1.1 - 255. Pick up a higher address so it won't be used by DHCP clients.
- Pick up a high port number, 5000, 10000, something you like that won't be easy to figure out, and use that as port to be redirected, and forward it to your access server's IP address, port 23 TCP for telnet, 22 TCP for SSH . You don't need to change port numbers on your access server, linksys routers should be able to handle this forwarding without problems. If your linksys model doesn't support this, there's always DD-WRT firmware.
- Everyone said this already, but don't forget to set a default route on your access server. I disabled IP routing and set it up with ip default-gateway command, but ip route all-zeros should work just fine as well.
- If it still doesn't work, then it's time to debug ip packets on your access server to see if it's even receiving anything when you telnet from outside. First time I was setting it, I had forgotten to set the default route, so an unroutable message helped me realize my mistake. Hopefully these should solve your problem.
I've got the same problem except I can't get telnet or SSH to work from the outside, most of the time.
We have Cisco 877s using c870-advipservicesk9-mz.124-24.T7.bin on ROM 12.3(8r)YI6
Both of the effected Cisco’s are using the above IOS\ROM, you can't connect using the dialler interface IP address (DSL) but you can connect if you use one of the IP addresses in the routed subnet range which routes to the dialler interface IP. There are no problems with telnet or SSH from inside the LAN on the Ethernet interfaces. I've completely gutted the configuration and replaced it with a config that I know works on another site for telnet on the dialler interface; they also have a routed subnet.
I've run a debug on telnet but when you telnet to the dialler interface from the outside you get connection refused and the Cisco doesn't log the fact that I've tried to telnet. Interestingly if I run a debug on TCP and do the same I can see the connection coming in on port 23, but the Cisco responds with an RST; the same is true for SSH.
If we change the dialler interface IP address to static rather than negotiated it works, we can telnet\SSH from the outside on the IP address of the dialler interface. If we revert back to IP address negotiated, then restart the dialler interface it still works and appears to be fixed. Yet, once the Cisco has been rebooted despite the configuration being saved we can no longer telnet\SSH from the outside on the IP address of the dialler interface. If we repeat this process, we can no longer telnet\SSH from the outside on the IP address of the dialler interface during any part of the process.
During all my testing I've set my access-list for telnet\SSH to allow from any source.
I’ve also used the rotary command to listen on different ports, but this makes no change and I’m running out of ideas. Could it be a problem with the IOS?
To give you a better idea of the problem, here is what we see when we connect using Telnet (in this case I've added the rotary line 1).
The first example shows a connection being made on the ethernet interface.
DATA 253 ACK 159679119 PSH WIN 64939
*Oct 17 22:38:11.600: tcp0: I LISTEN 192.168.1.1:58163 192.168.1.253:3001 seq 365991179
OPTS 8 SYN WIN 8192
*Oct 17 22:38:11.600: tcp0: O SYNRCVD 192.168.1.1:58163 192.168.1.253:3001 seq 2807504701
OPTS 8 ACK 365991180 SYN WIN 65535
*Oct 17 22:38:11.604: tcp0: I SYNRCVD 192.168.1.1:58163 192.168.1.253:3001 seq 365991180
ACK 2807504702 WIN 17520
*Oct 17 22:38:11.604: tcp3: O ESTAB 192.168.1.1:58163 192.168.1.253:3001 seq 2807504702
DATA 12 ACK 365991180 PSH WIN 65535
*Oct 17 22:38:11.608: tcp3: O ESTAB 192.168.1.1:58163 192.168.1.253:3001 seq 2807504714
DATA 560 ACK 365991180 WIN 65535
*Oct 17 22:38:11.612: tcp3: O ESTAB 192.168.1.1:58163 192.168.1.253:3001 seq 2807505274
DATA 274 ACK 365991180 PSH WIN 65535
*Oct 17 22:38:11.612: tcp3: O ESTAB 192.168.1.1:58163 192.168.1.253:3001 seq 2807505548
DATA 42 ACK 365991180 PSH WIN 65535
*Oct 17 22:38:11.616: tcp3: I ESTAB 192.168.1.1:58163 192.168.1.253:3001 seq 365991180
DATA 3 ACK 2807504714 PSH WIN 17508
*Oct 17 22:38:11.616: tcp3: I ESTAB 192.168.1.1:58163 192.168.1.253:3001 seq 365991183
This is what we see when we connect on the dialler interface.
ACK 893100756 WIN 16774
*Oct 17 22:40:01.209: tcp0: I LISTEN 4x.xx.81.8:36354 4x.xx.84.3:3001 seq 2640912120
OPTS 4 SYN WIN 4128
*Oct 17 22:40:01.213: TCP: sent RST to 4x.xx.81.8:36354 from 4x.xx.84.3:3001
We can see that the Cisco is configured to listen on all interfaces.
Active internet connections (servers and established)
Prot Local Address Foreign Address Service State
tcp *:23 *:0 Telnet LISTEN
tcp *:23 192.168.1.1:51368 Telnet ESTABLIS
udp *:67 *:0 DHCPD Receive LISTEN