Cliser - Client Server connector
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.
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
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:
It can always be downloaded from the Mosha site. For more information
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.
If you find that the binaries don't work under a particular operating system,
please let me know.
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.
- 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
- certain TCP/IP connections (especially ones that send data
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
- 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.
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:
An example cliser.ini file is available at the download page.
- 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
- 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.
(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
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
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.