Cliser - Client Server connector

Introduction

Cliser is a utility that allows one to make regular TCP/IP connections through a firewall which doesn't allow arbitrary TCP/IP connections. Instead, it will use a normal HTML proxy and send its requests through this proxy to a special server on the Internet, which will translate these requests and forward the connections to the desired location. In theory any connection can be established this way, but "cliser" is currently still an alpha product and might not operate as desired. Cliser will also do a rudimentary form of encryption on your data stream, to protect it from being decoded by the proxy.

ID

The current version of the gateway requires an ID to be sent. This is possible by entering "id=(id)" in the cliser.ini file, if you're using version 1.10b or higher.

Available versions

Cliser is currently at version 1.14, though some executables might have an older version. You can tell the version by running the executable, it will appear on the command line. No guarantees are made for these executables, and the copyright is with Mosha (v.o.f.).

Currently there are three binary versions available for download:

32-bit Windows version (cliser.exe) which should work under Windows'98 (tested), Windows'95, Windows-NT (tested), Windows-ME, Windows 2000 (tested) and probably also windows 3.1/3.11 with the 32-bit extensions enabled. Windows XP should work too, but wasn't available when this binary was compiled.
Intel (compatible) linux version (cliser_linux) compiled on an ELF system with glibc 2.0. It should work quite well on other systems as well.

It can always be downloaded from the Mosha site. For more information see http://www.mosha.net/77-downloads/download.shtml.

If you find that the binaries don't work under a particular operating system, please let me know.

Usage

To use cliser, you need to start it from a command prompt window. Without parameters, it will show a usage text:

Usage: cliser <proxy name> <proxy port> <remote site>
[<remote port> [<local port>]]

Obviously, you will need to know the proxy name and port of the proxy server that you use. These can be obtained from your browser settings. In Internet Explorer, these are usually located under view->options->connection->proxy. In Netscape, these are usually located under edit->advanced->proxy. Use the HTTP settings. In case you're conecting through a NAT firewall, and feel that you might not need proxy settings, you could try using "mosha.net" and "8080" as the proxy server and the proxy port.

The remote site is the site that you would want to connect your TCP/IP connection to. It could be a talker, MUD, SMTP, POP3, IMAP, HTTP or any TCP speaking process. The remote port is the port of this process, and is optional: without the port, 23 (telnet) will be assumed.

The local port is the port on the local machine that you wish cliser to bind to. By default this is port 5317. This is the port you need to connect to once cliser is running. Note that many operating systems will prevent you from using ports below 1024, or even 2048, as these are usually system ports. But if your system allows it, you can change the port number to 110, and connect to a POP3 server, to read your mail through a firewall.

After cliser is running, you can connect to it using any TCP client you might have available locally. You can connect both from localhost, but even from other machines on your side of the firewall, by using your own IP address.

Notes

cliser requires the telnet2HTTP server to be running on mosha.net, and that this server is reacheable through your firewall. You can check whether this works for your connection by using the regular telnet interface.
certain TCP/IP connections (especially ones that send data character-by-character) might cause a large amount of requests being sent to the proxy server. Apart from the load this might cause, it might also result in a significant amount of log messages generated by this proxy.
In case of a process that keeps sending messages: there is no guarantee that the proxy will send these in the same order. cliser will currently not keep track of this order either, therefore such processes might have problems with their connection.
In case of a process that sends large messages (like SMTP): some proxies have a limited URL size. If this is the case, you might want to reduce the blocksize to a lower value. See an explanation of the cliser.ini file on how to do this.
SMTP (port 25) will receive their connections from the telnet2HTTP server. Usually these SMTP servers will check the origin to avoid spam. So it might be impossible to send mail from your regular SMTP server. To ensure delivery, it is recommended you connect to the SMTP sever of your mail's destination.
ftp (port 21) also uses UDP on port 22 for the actual file transfer. It is therefore possible to browse using cliser, but it is NOT possible to actually transfer files. Usually, however, a proxy has their ftp port open, so you could just use the proxy for this purpose.
If your proxy uses authorization, from version 1.08b on you can enter your password and username in the cliser.ini file. Please give me feedback on this functionality if you use it.

cliser.ini

It is possible to create a cliser.ini file, with some configuration options. The format of this file is a line based definition of variables, separated by equal signs (=). Currently the following variables are supported:

blocksize: This is the size of the blocks send to the proxy. Some proxy have a limited block size. The minimum is 300, the maximum is 20000. The default is 20000, as the blocksize should preferably be as high as possible. If this doesn't work for you when sending large packets (e.g. mail) you might use this parameter to reduce the blocksize.
timeout: In case cliser complains about proxy timeouts and you seem to get abnormal behaviour from your connection, you could increase the value for the time out, which is default set to 2. Usually the time outs to the proxy should not affect your connection, however.
localport: This is to override the default value of 5317 for the localp port. The command line still has priority.
remoteport: This is to override the default value of 23 for the remote port. The command line still has priority.
username: Only useful in combination with password. It has a maximum length of 32 characters and is the username needed to access a proxy that requires authorization (in versions before 1.13, this was 16 characters).
password: Only useful in combination with username. It has a maximum length of 32 characters and is the password needed to access a proxy that requires authorization. If you add a password to the cliser.ini file, please make sure that it is difficult to access for other users (in versions before 1.13, this was 16 characters).
allow (version 1.09b and higher): Restricts access to cliser to the IP address specified in allow only. useful if you are afraid that the open cliser port on your computer/server is going to be misused by other people. To retrict usage to localhost, use 127.0.0.1 as value.
id (version 1.10b and higher): The gateway now REQUIRES an ID to be sent to identify your connection. If this value is absent, you will not be able to establish a connection.

An example cliser.ini file is available at the download page.

Example

(The sites mentioned in this example are hypothetical, and should be replaced by the names that you wish to use).

If you are behind a firewall with proxy "proxy.business.com" at port 8080, but would like to connect to "fun.server.org" at port 4040, you would run cliser as follows:

cliser proxy.business.com 8080 fun.server.org 4040

This will open port 5317 on the localhost, and will allow you to, for example, do:

telnet localhost 5317

Which will seem as if you were doing a telnet to fun.server.org 4040.

In case cliser is running on machine 10.1.1.1 and you are currently working on 10.1.1.2, you could still use cliser, by doing:

telnet 10.1.1.1 5317

As long as both machines are on the same side of the firewall, and the allow value (version 1.09b and higher) in the cliser.ini file isn't set to restrict this.

If you would like to read mail from "pop3.server.org", which would usually be at port 110, you could run cliser as follows:

cliser proxy.business.com 8080 pop3.server.org 110 110

This will open port 110 on the localhost, and will allow you to configure your mail to access the POP3 protocol at localhost rather than pop3.server.org, which might normally be unreacheable due to the firewall. As said before, opening local port 110 might fail because of operating system restrictions. If this is the case, you'll need to choose a different port, and try to reconfigure your mail reader to use this other port.