Allow Rainbow 6 Raven Shield LAN games to be played outside of a LAN, enabling true cross LAN and cross site multiplayer games. This has been tested to work over multiple VPNs connecting cable modems and adsl modems. The relay will run on a Linux machine acting as firewall, or, using the Windows version on the machine that runs the Rainbow 6 game. Tests have shown all client subnets (but not the server subnet) require rain6relay. Tests forwarding ports without using a VPN have not yet been made. If you have machines connected via a LAN but on different subnets, that will also work - this amounts to the same situation as a VPN.
A port to Windows is provided, run from an msdos prompt.
Look in the ToDo section for more Windows references.
Has been tested to work with patch level V1.0.
rain6relay.c - the Linux/Windows source
rain6relay.zip - the Windows executable
gcc -O2 rain6relay.c -o rain6relay
where the IP addresses are machines potentiall running Rainbow 6.
rain6relay needs to be running on the subnets of all Rainbow 6 client machines, this normally means each client must be connected via a switch to an instance of rain6relay.
rain6relay without a VPN:We have yet to test this scenario. It looks like you need to forward UDP ports 5777, 7777, 8777 and 9777 to 9782, but as this is untested we don't yet know for sure.
Controling serial number checking:If you are using metered ADSL 'dial-up' and want to stop Rainbow 6 from phoning home to confirm your serial number, try blocking all UDP access to the ubi subnet of 188.8.131.52/20. This works well for V1.0 of R6, but later versions (such as V1.56) are much harder to contain.
Theory of operation:
The job of rain6relay is to relay broadcast packets sent out by Rainbow 6 when looking for a game server. Once the clients/server know each others IP address, there is no need for rain6relay as the clients/server talk directly to each other using the IP addresses obtained during the broadcast (or rain6relay's relayed broadcast).
As broadcast packets only spread as far as the subnet from which they originated, Rainbow 6 clients can't normally find Rainbow 6 servers on a nearby subnet. rain6relay looks for these broadcasts and sends a copy of what it receives to the IP addresses given as arguments. Rain2relay fakes the source IP addrees, so the relayed broadcast packet (which is no longer a broadcast as it is sent directly to single machines) looks like it came from the original machine, making the packet relay process transparent.
For example, if 192.168.15.51 is the Rainbow 6 client, 192.168.0.7 is the Rainbow 6 server,
both machines (and networks) are connected by a Linux machine on IPs 192.168.15.1 and 192.168.0.100.
When told to look for LAN games, Rainbow6 looks for servers by sending out a udp
broadcast to port 8777 (among others, but that doesn't seem to matter):
192.168.15.51:9777 -> 255.255.255.255:8777 udp length 6 (subnet 192.168.15.0/24)
rain6relay receives the broadcast, and sends it to the other given IP faking the original sender IP address:
192.168.15.51:9777 -> 192.168.0.7:8777 udp 6 length (subnet 192.168.0.0/24)
Rainbow 6 server will receive this spoofed packet and accept this as if it was a broadcast on the same subnet by the client.
When the clients and server are not on nearby subnets, the same idea still works but in this case rain6relay needs to redirect the clients packet across a VPN.
Playing externally across sites without the VPN will probably need additional changes, to send the firewall IP as the source address rather than the private IP. Its possible that you don't need this, as there is a "NAT Local connections" kernel configuration option which might NAT the spoofed packet correctly.
As a more general solution, look for the Gamers Internet Tunnel. Don't know if this supports Rainbow 6, but it could do.
As an even more general solution, you can look at OpenVPN, a secure cross platform VPN. Seems to work for rain6relay, but you do need to tell OpenVPN about your subnet. Look in comments of rain6relay.c for more info.
in_cksum(), pseudohdr and udpsend() came from a German language 'hacker' howto, one of the few examples of RAW packet generation that actually generated well formed packets.
Other code and the main idea came from Richard Gregory, greg at csc.liv.ac.uk
Hacked this up in a about an hour, as it is based on nfsu2relay.
Relayed packets now use the same source address as the client, making the relay work more than once in a session.
Modified web page to talk about experiences when patching R6.
Synced this version with my test version, my test version worked slightly better. Compiled a version that runs under Windows.