Telnet on a port other than 23

by Dirk Hart Email: [email protected]

The other day I was asked to add a terminal server to a customers system. They had dumb terminals and a printer in a remote office that they wanted to connect to a local system. There was a Computone Intelliserver in the office so that was the candidate for the job and the customer had previously ordered up DSL for both sites so I was ready to go.

A quick check proved I could telnet to either router. What I really wanted to do though, was to have the remote site telnet to the SCO system at the local site. Since I also wanted to be able to have the DSL providers telnet to the routers for maintenance, port 23 (telnet) was unavailable to me.

Since the Intelliserver is able to do telnet on any port you tell it to I chose 2023 and configured it accordingly. That way telnet sessions initiated on a dumb terminal at the remote site would go out from port 2023. I found the intelliserver particularly easy to configure as it is unix based - it has an actual unix kernel running.

A quick call to the DSL provider for the local office put me in touch with a smart guy who arranged for packets on port 2023 to pass through the router to the IP address of the SCO machine. This was a private address (192.168.x.y) as there was Network Address Translation (NAT) already in place.

As you probably know telnet doesn't usually work on port 2023, but the beauty of unix is that you can usually do what you want. So I edited /etc/services and added this line:

telnet 2023/tcp

Looked good, but it didn't help me telnet to port 2023. After a few moments of muttering I added the following to /etc/inetd.conf:

telnetw stream tcp nowait NOLUID /etc/telnetd telnetd

and changed /etc/services to:

telnetw 2023/tcp

Note that these entries describe a unique service (telnetw) on port 2023. Another quick check proved I was able to telnet to the SCO machine on port 2023.

So far so good, but I realized that printer traffic bound for the remote site would be blocked at the remote router. That's no good, so I went to poke a hole in the remote router myself, as the DSL provider would have no part of it nor would the router tech support folk. I reasoned that I needed to add a rule to the existing Basic Firewall Ruleset that already existed on the router. And since the Intelliservers come with a dandy bit of software that sets up a device node that takes incoming data and shoves it out port 9015 (corresponding to the 16th serial port on the intelliserver) I decided that my firewall rule should allow all traffic on port 9015 to move directly from the router to the intelliserver. I read the technotes that explained how to do this, and the caution that if you had NAT enabled that you should use the private IP address of the router, and so I wrote my rule accordingly.

The more experienced reader may already know that adding firewall rules to a router that already has NAT enabled is by and large redundant, however I am more experienced now than I was then. In any case I added my new improved Basic Firewall Ruleset to the 'active ruleset' and in the process failed to notice that there was currently no active ruleset. Had I noticed I might have paused to wonder what might happen to traffic on port 23 and whether I would be able to telnet in to the router. Well, I didn't notice and about a second later I realized that I had turned off port 23.

The next day I arrived on site and after a short conversation with the router manufacturer's tech support (relating my tale of woe) I knew that I didn't need a ruleset at all when NAT is enabled. We added a service on port 9015 (and 9014 and 9013 in case more printers were added later). In minutes I had a login on a dumb terminal and was printing on the printer.

In a while I had all the wiring in place, all the terminals online and the printer printing. The 2 1/2 hour ride home was far more enjoyable that the ride to the remote site.



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Telnet on a port other than 23




Increase ad revenue 50-250% with Ezoic


More Articles by © Dirk Hart




I was reminded of this by someone else today.

This is, of course, a very bad idea, because it is telnet. The "2023" doesn't help security any - modern port scanning will find that almost instantly.

Use ssh or a vpn.

--TonyLawrence



Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





Several people have told me that my inability to suffer fools gladly is one of my main weaknesses. ((Edsger W. Dijkstra)

I define UNIX as 30 definitions of regular expressions living under one roof. (Donald Knuth)








This post tagged: