UDP from behind proxies

Eating Before Swimming (mathboy@sizone.org)
Fri, 23 May 1997 12:10:29 -0400 (EDT)

My brother wrote this up for our group, thot I'd repost it.

This wont help you unless you can run UDPRELAY right ON the
firewall in which case I spose I might call it a proxy...

This is useful for people running their own gateway to appear as one
entry in the stats (someday ;) but have to use a proxy (single dynamic
dialup IP for a network of machines at home, for eg).

then Andrew Chase's all..
From: Andrew Chase <fixy@crystal.palace.net>
Subject: UDP from behind firewalls/proxies
To: deschall@semiotek.com
Date: Sun, 18 May 1997 16:32:50 -0400 (EDT)

This message details how I got UDP to work from behind my

First I'll talk about the methods I tried which didn't work,
so no one else makes the same mistakes. If you don't want to read
what didn't work, skip to [ What Worked ] section below.

[ What Didn't Work ]

I tried first to use the u2t perl script.. but that was just
sillyness, since it converts a UDP request from a client on my lan
into a TCP HTTP GET call.. so using that with an argument of
solar.upowered.org means that you'd only be using the web proxy
on solar.upowered.org, not the actual deschall proxy. That's no good.
It would only work if you could modify the script to do a UDP request
-> another UDP request (which is basically just a relay). But that's
too much work, and there are better ways.

Next I tried looking at socks to see if it could handle UDP.
socks4 cannot, but socks5 claims it can. Great I thought, so I installed
socks5 beta 10. Being a beta, I tested it with my web browser first..
and it worked.. but five minutes later stopped working. That's fine,
I thought, I'll sacrifice being able to browse the web in exchange for
DES UDP working. As it turns out, I never got a chance to try the
UDP capabilities of socks5 because it occured to me that I'd need
the client to talk to port 1080 (socks port) of my sockd proxy, not
UDP port 8669 as it normall does. Bad bad bad. Then I read that
there's a program that comes with socks5 called runsocks, which
you run like this: 'runsocks <program> <program arguments>'. So I
would run 'runsocks deschall-linux-P5 solar.upowered.org' However
I never tried it, because my copy of socks5 didn't have a similar program
for my windoze '96 boxes. So I scrapped the whole socks5 thing and
went back to socks4, as well as looking for another method.
(I later read that there is infact a program to "socksify" windoze
programs too.. but never bothered going back. This was all just
too much hassle).

[ What Works ]

I read about a program (actually a daemon) called udprelay and
went off in search of it. I never found its homepage, but did locate this:
Ignoring the bsdi part (considering I run linux here at home), I
grabbed it and decompressed it to find source code. Whee! I compiled
it (the makefile actually tries to compile 3 files, it compiled udprelay
the binary, then failed on the next two. I later found out that those two
files are unncessary and so ignored them), and read the docs. It's
vastly simple.. you run the daemon with the following arguments:
udprelay -f <config-file> & as root or from an rc.* script.
(I put it in rc.inet2, personally). The config file is also
pretty simple, my config file (/etc/udprelay.conf) reads as follows:

relay * * 8669 solar.upowered.org 8669 any

That's it. The first star is where to accept requests from.. as in,
host names. You could put *.your.domain there if you wanted, I just
put * since it doesn't matter who accesses it. The second asterix is
what remote ports to accept requests from. Since I don't know which
port the client calls FROM (I know it calls TO 8669), I put a *
there. You could probably assume that it calls from 8669 too.. but
who knows? * * works well for me. The next argument, 8669, is
what local port to accept from. Since the client talks to 8669,
this is pretty static. Next comes what remote host to relay the UDP
request to. solar.upowered.org to use the upowered proxy, else
use keymaster.verser.frii.com if you're not with upowered. The second
8669 argument is what remote port to relay to. Since the
u2t perl script listens for client requests, it's listening to 8669.
So again, 8669 is pretty static. Finally, the "any" at the end is what
direction the UDP can flow in.. you can make this "one-way", but
then you'd never get new keys.. "any" means that the UDP requests
coming in from solar.upowered.org:8669 can flow into the LAN.. in other
words, a two way communication such as is required for DES.

Well, that's it. That's how I have my setup configured here at
home, and it works.. and has been for about 2 days now. Sorry that was
a bit lengthy, but it covers alot. Let me know if anything was unclear
or if something doesn't work.

--Andrew Chase

Ken Chase mathboy@sizone.org Sonic Interzone $free$ email/news Toronto Canada
Join the DES Challenge! Wake up the US Govt!   www.frii.com/~rcv/deschall.htm