[Techtalk] url port forward?

[Almut Behrens]

On Fri, Oct 01, 2004 at 11:08:53AM -0400, overhaul wrote:
> 
> I have a webserver that will only allow port 80 access from a select few
> source ip's.    I am trying to set up a sortof url "hop" so I can access
> this server from anywhere by making it look as tho I'm coming from one
> of the allowed ip sources.     The reason for this is my home ip is
> dynamic and I don't want to have to constantly update the ipf rules on
> this server everytime my ip changes.  Opening the server up to my entire
> isp is not an option either.
> 
> I was told I could set up something called a "url forward?" whereby I
> can access server "A" from server "C"(home) by pulling up a url on
> server "B".  server "B" which is allowed access by "A" then redirects
> the request coming from "C" to "A" giving it it's own source ip.
> 
> I know how to setup port forwarding on a router but I don't want to
> forward EVERY request on B to A and I don't think that changes request
> source ip anyway.
> 
> I hope my desription isn't too confusing.
> 
> I'm thinking it has to do with proxy.   apache module mod_proxy.c.. 


Exactly, that's the way to go.  What you want to set up with mod_proxy
is a so-called "reverse proxy".  So, on your server "B" you'd have to
run apache with the following additional options in httpd.conf (in its
most simple form):

ProxyRequests     Off
ProxyPass         /  http://your.internal.server/
ProxyPassReverse  /  http://your.internal.server/

A detailed description of what this does can be found in the reference
docs:  http://httpd.apache.org/docs/mod/mod_proxy.html (for 1.x
versions)  or http://httpd.apache.org/docs-2.0/mod/mod_proxy.html
(for apache 2.x -- note that mod_proxy for 2.x has more features, and
works somewhat differently).

Of course, for this to work, the mod_proxy functionality has to be
made available by loading the module dynamically, i.e. "LoadModule
proxy_module libexec/mod_proxy.so"  (or by having it statically
compiled into apache).

For simple reverse proxying tasks this should work as is, but there
are some issues with this approach, for example having to do with
absolute HREFs inside the delivered HTML code, etc.
(For the latter, see http://apache.webthing.com/mod_proxy_html/).

There's a very good tutorial article by Nick Kew (the author of
mod_proxy_html), focusing on the apache 2.x way of doing it:

http://www.apacheweek.com/features/reverseproxies

So, rather than rephrasing everything he says in my own words, I'll
just suggest you read that article :)


For very simple cases (if no "ProxyPassReverse" functionality is
required), a simple port forwarder (an application level program, that
is, here), can be used in place of the apache + mod_proxy solution.
As it runs as a normal user-level program, the webserver on "A" would
see the request as coming from the IP address of "B" -- which is
exactly what you want.

Theoretically, the netcat utility could be used for this (e.g.
http://packages.debian.org/testing/net/netcat).  This tool is so
flexible, however, that its proper usage for that very purpose is not
immediately evident to most people ;) -- and also, it gets somewhat
cumbersome, if you need to port-forward multiple connections
simultaneously with it (even a single browser normally opens many
connections simultaneously to the same server...)

There are a variety of other port forwarders available, e.g.
http://sourceforge.net/projects/portfwd/  (google for more),  but all I
know of have their particular quirks, so I ended up writing yet another
one myself (a simple perl script), which you can of course have if you
want to try that route...

If performance is an issue, I'd suggest you use the apache solution,
as apache provides optimized techniques for handling multiple requests
(either by preforking or threads -- in contrast, my simple perl script
just does fork-on-request, which is undoubtedly slower).


Last but not least, there's a more general issue to think about: for
this whole approach to be of any real value, you'd have to make sure,
that the apache (or port-forwarder) on server "B" is only accessible by
"C"/you (either by having it located somewhere where only you have
access, or via some other special authentication mechanism...).
If server B is open to the public, then you wouldn't have gained much.
You'd only have moved the issue of which IPs to allow, from server A
to B  (-> if anyone could connect to the proxying service on B, and B
forwards the requests to A, then you could just as well let people
directly connect to A -- from an access control point of view...)


I hope this wasn't too confusing... Anyway, if you get stuck somewhere,
don't hesitate to ask for more details :)

Almut