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
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:
Looked good, but it didn't help me telnet to port 2023. After a
few moments of muttering I added the following to
telnetw stream tcp nowait NOLUID /etc/telnetd telnetd
and changed /etc/services to:
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
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.
Increase ad revenue 50-250% with Ezoic
More Articles by Dirk Hart
© 2011-04-30 Dirk Hart