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:
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:
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.
More Articles by Dirk Hart © 2011-04-30 Dirk Hart
A learning experience is one of those things that say, "You know that thing you just did? Don't do that." (Douglas Adams)