Back to files

This small application is a simple GG relaying agent. This means, that if you are a network administrator and applying masquerade on your server, it's likely, that your customers would like to establish direct connections over the masquerade using GG. This program is intended to be the solution.

NOTE: Please read "NOTE on GG6.0" below.

Prerequisites

Current version is written to compile and work cleanly on a little-endian (Intel-endian) machine with GNU/Linux. Perhaps future releases will be more portable.

Installation

login as root
run ./install.sh
run /etc/init.d/ggrelay start
iptables -t nat -A PREROUTING -i <internal interface> -p tcp \ --dport 8074 -j REDIRECT
iptables -I FORWARD -o <external iface> -d 217.17.41.0/24 \ -p tcp --dport 443 -j REJECT

See below for more information about setting up iptables rules.

Configuration

All configuration options are to be passed directly on the command line. Minimal configuration includes your external interface, to which incoming DCC connections will be redirected:

ggrelay -o ppp0

In this case all connections to port 8074 will be caught and managed so, that DCC connections will come to default IP on ppp0 and port number 1550 (yes, all to the same port) and then will be redirected to appropriate clients according to uins sent by remote clients.

Other interesing options include setting interfaces to be listened for incoming GG (not DCC) connections (-i option), setting ports for GG and DCC listeners (--gg-port, --dcc-port). Another useful parameter is -u, which forces ggrelay to setuid to the specified user. The -d switch tells ggrelay to fork into backgroud after successful initialization. So in general, it's reasonable to run ggrelay with:

ggrelay -i <your internal interface> -o <your external interface> \

-u nobody -d

The next step is to configure netfilter (iptables) stuff to redirect connections from your client machines to ggrelay. It can be simply accomplished by

iptables -t nat -A PREROUTING -p tcp --dport 8074 -j REDIRECT

Next step should be opening port 1550 on all interfaces for incoming DCC connections and port 8074 on internal interface (only if you have port filtering enabled).

Plase beware, that if ggrelay fails (or won't be launched), then connection attempts from your clients would be redirected to /dev/null, so make sure that ggrelay is running whenever REDIRECT rule exists in iptables.

Attached install.sh was written to aid in configuring startup scripts. It creates standard rc-scripts (written for RedHat/Fedora environment, what doesn't necessarily mean, that they won't run on other installations) in /etc/rc.d/init.d. It also creates interactively /etc/sysconfig/ggrelay, which contains some parameters, which are then passed to ggrelay by /etc/rc.d/init.d/ggrelay script.

Configuring clients for DCC

There is no special configuration for ggrelay is needen on clients, just standard enabling of direct conections:

on ekg: run 'set dcc 1' and then 'reconnect'
on Kadu: check 'Enable DCC' in Kadu -> Configuration -> Network tab.
on Windows GG: check Ustawienia -> Polaczenie -> Uzywaj polaczen bezposrednich. No further configuration is needed, only enabling DCC.

For successful work with DCC both ends have to have above settings applied.

NOTE on GG6.0

GG 6.0 (and possibly some earlier versions) introduced a) pedantic checks regarding dcc connections source/destination IPs b) SSL cryptography

ggrelay is now able to overshoot the first issue without addidtional configuration.

The second problem is cryptography - GG6 uses SSL by default and ggrelay does not support it reliably. There is a possibility to change the behaviour of clients without need to setup anything on the clients. Simply blocking communication to gg servers on port 443 causes GG6 to switch to non-encrypted plain communication on standard 8074 port. As it is not the best solution now, I'm working on incorporating cryptography support into ggrelay, currently it exists in the source but is highly experimental and is even not expected to work.

So it's needed to run:

iptables -I FORWARD -o <external iface> -d 217.17.41.0/24 -p tcp \

--dport 443 -j REJECT

SSL support (highly experimental)

Starting with ggrelay-1.0-rc3, there is experimental support for OpenSSL cryptography for forwarding secured connections. Currently main goal is to make it WinGG-compatible (so it is not yet).

If you want to enable SSL, there is a small setup script called 'sslsetup' in the scripts/ directory, which will help you configuring SSL. You can also do it manually:

generate server private key and certificate using

openssl req -x509 -newkey rsa:1024 -keyout <key filename> \

-out <certificate filename> -nodes

b) add parameters to ggrelay's commandline:

        --ssl-key <key filename>
        --ssl-cert <certificate filename>

To catch incoming SSL connections, traffic addressed to GG servers' port 443 is to be redirected to local machine, port 8075 (can be overriden with --ssl-port). Sample command:

iptables -t nat -A PREROUTING -p tcp -d 217.17.41.0/24 --dport 443 \

-j REDIRECT --to-ports 8075

Server selection strategy

Starting with version 1.3-rc1, ggrelay uses new strategy to select GG server to connect to (the previous one was to select from a list in the round-robin fashion). Now the process has two stages. At first a connection to ggrelay is looked for original destination address. It means, that REDIRECT'ed connections are forwarded to the same host they were addressed to. But before doing that, destination address is checked against specified servers list. If it is found, it's ok. If not, the connection is either dropped or directed to stage 2 selection. This behaviour depends on whether --drop-unlisted was specified on the command-line.

If for some reason, the first stage is unable to determine destination server, it is selected from the list built using -s command-line options. Now server is not chosen using strict round-robin strategy, but broken servers are getting lower preference.

Moreover, if connection with a server fails, it's retried, up to several times, as specified by --conn-attempts.

All commandline options

-i <ip/if>, --inner-ip <ip/if> internal IP/interface -o <ip/if>, --outer-ip <ip/if> external IP/interface (recommended)

  -d, --daemonize                 go to background after
                                                       initialization
  -s <ip>, --server <ip>          add GG server
  -u <user>, --user <user>        suid to specified user at startup
  -m <num>, --gg-limit <num>      max. number of chat connections
  -n <num>, --dcc-limit <num>     max. number of DCC connections
  --conn-attempts <num>           number of attepts to connect to the
                                                                server
  --drop-unlisted                 drop connections to servers not
                                                       specified by -s
  --static-buffers                disable dynamic buffers allocation
  --gg-port                       override chat port
  --relay-local                   catch also local-network connections
  --cascade                       turn on cascading-compatibility
  --scalable                      use bigger hashtables for large
                                                              networks
  --dcc-port                      override DCC port
  --ssl-port                      override SSL server port
  --ssl-key <file>                SSL server private key
  --ssl-cert <file>               SSL server certificate
  -l, --logging                   enable connections logging
  -v, --verbose                   repeat all messages to stderr,
                                                enable debug messages
  -h, --help, --usage             show usage information
  --version                       show version information

SECURITY WARNING: Enabling --logging introduces risk of log-flooding.

NOTE: If you plan using GG client on the masquerading machine, please consider using different port for dcc, using --dcc-port, for example:

ggrelay -o ppp0 --dcc-port 1551

Additional notes

"dcc rsend" sent to ggrelay'ed client will fail, but it is always possible to use direct "dcc send". The first should work in cascading mode.
there is a new command-line switch --scalable, which enlarges UIN hashtables managed by ggrelay to meet large networks requirements. So if you have problems in large network, you may try passing --scalable to ggrelay.

Troubleshooting

All observed bugs/problems and feature requests please direct to me using SourceForge <http://sourceforge.net/tracker/?group_id=96768>. Please don't hesitate to contact me privately on accek[at]poczta{dot}gazeta<dot>pl if you have serious problems with this software. But before doing that, please review all revealant documentation.

Please attach following information when reporting problems running ggrelay:
a) ggrelay version (ggrelay --version)
b) iptables version (iptables --version) c) kernel release (uname -a)
d) 'iptables -v -n -t nat -L' output
e) 'iptables -v -n -L' output
f) /etc/sysconfig/ggrelay
g) messages generated by ggrelay compiled from sources using

'./configure --enable-debug' and started from the shell with

ggrelay -i ... -o ... -l -v (without -d) after some time, when trying to connect to the GG server or when attempting to establish DCC connection, etc.

Credits

I would like to thank all the people, who have helped me developing ggrelay.

Especially, best regards to

Przemyslaw "Przemo-c" Dubiel

for spending so much time testing the application, providing to me an account on his server, and much more. Thank you, Przemek!

Author

Szymon Acedanski
ul. Sloneczna 81D/1
40-136 Katowice, POLAND
phone: +48 506 202715
email: accek{at}poczta[dot]gazeta<dot>pl

vim:tw=70