I'm helping a friend out, and I need someone to point me in the right direction. I'm just not sure what software I should be looking at for this particular issue.

What I know about proxy servers is usually backend stuff. You set one up, put the configuration in the program (usually a browser) and everything runs through that proxy. Alternatively some programs set up a tunnel and proxy everything that way.
Those aren't what I need. Here is the scenario

1. Remote webserver that people will use
2. a remote website they need access to, but it will only take connections from a specific ip address (which is not the web server)
3. another machine sitting at that that specific address that we can do anything with.

What we'd like to do is set up something on the webserver in the form a link where they can click it, and it will take them to that machine which will work as a proxy to access the website.
I understand it in theory, but the only proxy stuff I've done has been backend stuff above. We don't want the users to have to configure anything on their end. We don't have any control over the remote website itself. But users will need more than read access. They'll have to interact with and log in to that site, then navigate it.

1. Has anyone seen anything like this before? The main server/site is not acting as a proxy, it simply will hold a link to the actual proxy server
2. Is it possible?
3. Can anyone point me in the direction of which particular software I should be looking at to handle this? I can go there and read tutorials and hit up their forums for more specifics.

I reread your post a couple of times but I'm still unsure about your exact desired set-up. Let's clarify it:

How many machines are involved in the set-up? 3?
How many of them with public IPs? 1?
Is the site with the link publicly accessible but the one where users go after clicking the link - on a private network?

Yes, I thought I should draw a picture.
3 + the user
The user will connect to a public webserver with a public IP
the user will need to click a link there that will take them to the proxy server, which has a public IP as well (entirely different physical location)
that proxy server will connect to the other site they need to use
The last one is also publicly accessible but will only let them log in from the proxy server. The difference between this and a regular proxy server is that we can't really have the user configure anything on their end.

I'm on my way out, so here is a very very rough diagram.

http://img861.imageshack.us/img861/2991/proxyvl.png The main webserver will contain nothing but a link, so I don't think much has to be done there, I just need to figure out which software to run on the proxy server that will server up the content from the other machine seamlessly.

It's very straightforward then - you use a reverse proxy (say, Nginx or Apache). A potential problem - "We don't have any control over the remote website itself" - if you don't control that site webmasters there can simply block you from proxying.

1 members found this post helpful.

I don't think that seems to be a concern for my friend who has some kind of contract with them. Apparently people usually use it from the location of the proxy server, but occasionally they need remote access, but are either unable to, or unwilling to setup a proxy at their home. I guess for the once in a blue moon they need this, they'd like there to be no setup on the users part. I'll look into reverse proxy, thank! I've been taking a break from Linux since about FC6, I know they're on a fast upgrade cycle now or something. Any particular distro I should be avoiding these days? I was figuring to go with either FC since it was mostly what I used, or perhaps Ubuntu as it seems to be the other go to.

Choose a mature server-oriented distro with long support - (in my order of preference) Ubuntu LTS, CentOS, Debian Stable. If you are more familiar with Red Hat-derived distros then you may prefer CentOS (choose it over Fedora for support term and stability).

1 members found this post helpful.

Thanks again!