port mapping with apache

[blasto]

hi,
we have a firewall config. that enables an outside user to connect to his local computer via rdp by pointing out our domain name with his specific port, for example:

ourdomain.com:1111 <-mapped to--> internal-pc1:3389
ourdomain.com:2222 <-mapped to--> internal-pc2:3389

at some places ports other than 80 are blocked so we cannot connect to our custom ports. is there a way to map different virtual names (bound to apaches port 80) to our internal pcs? for example:

pc1.ourdomain.com:80 <-mapped to--> internal-pc1:3389
pc2.ourdomain.com:80 <-mapped to--> internal-pc2:3389

I've checked mod_proxy but couldn't figured out a way. anyhelp is appreciated cause this is an emergency.

ps:we have only one static ip addr. matching our domain name

[gergoe]

The only way (I know of) to use the proxy module built into the Apache is that you can use it as a HTTP proxy. A client can connect to your Apache server, it issues commands like "GET [remote_server...] HTTP/1.1" then your Apache will fetch that URI and will send whatever it received, back to the client. You can also use it for other protocols like HTTPS or even RDP, but there's a small problem. It is a proxy after all, not a gateway, thus the client (in your case the terminal services client) would need to issue a HTTP command (CONNECT internal_ip:3389) to the Apache before it could initiate an RDP connection to your internal pc, and this is hardly possible.

So, using Apache you can't do this. There are alternatives, for example in Windows 2008 Server there's a new "feature" called Terminal Services Gateway (TS Gateway), that's something you are looking for...

[blasto]

thanks gergoe,
finally you brought some light, I've been looking for an effective solution for this problem but its obvious that it won't be solved without a special software as you've suggested.

[blasto]

ok here is another indirectly related issue:
I want to free up port 443 which is now used by apache, instead I want to use another port like 81 for https. our https usage is not puclic but its just used to encyrpt login data. I've tried local proxying, below are our main virtualhost directives in http.conf :

Listen 80
Listen 81

NameVirtualHost *:80

<VirtualHost *:80>
DocumentRoot C:/Inet/www/
ServerName www.ourdomain.com
</VirtualHost>

<VirtualHost *:81>
DocumentRoot C:/Inet/www/
ServerName www.ourdomain.com
SSLEngine On
SSLCertificateFile conf/ssl/web.crt
SSLCertificateKeyFile conf/ssl/web.key
</VirtualHost>

<VirtualHost *:80>
SSLProxyEngine On
ProxyRequests Off
ServerName secure.ourdomain.com
ProxyPreserveHost On
ProxyPass / [ourdomain.com:81...]
ProxyPassReverse / [ourdomain.com:81...]
</VirtualHost>

with this setup I want to be able to reach our https site by pointing out secure.ourdomain.com address. But I couldn't.. The very same setup is needed to proxy to our secure webmail service running on a different port. Its ok when its plain connection but I'm out of luck with ssl. I'm doing smth. wrong or I got the whole idea wrong?

[gergoe]

There's only one important thing you have to remember when it comes to SSL and virtual hosting: name based virtualhosts are not working with SSL. The SSL protocol is initialized prior to any HTTP messages, and at the initialization phase, the server already need to know which certificate file to use, thus, it needs to know which virtualhost to take - which is only determined after the SSL connection has been initialized.

It means that each SSL secured website (virtualhost) must have it's own ip address, or port number (or both), that's only only way for the Apache to determine which virtualhost to use

I'm not sure of the behavior of the SSLProxyEngine directive, but probably it proxies the SSL protocol from the remote server to the local server (and to the browser), so it has the same behavior as a "normal" SSL website, which means you have to put it on a different ip address or different port.

But I don't get the idea of running a https website and proxying the same thing to the same server on a different name (on the http port)? If you only want to make secure.example.com SSL secured too, then you should only make one SSL enabled virtual host, and that virtualhost must be declared like this:

<VirtualHost *:81> 
DocumentRoot C:/Inet/www/ 
ServerName www.ourdomain.com 
SSLEngine On 
SSLCertificateFile conf/ssl/web.crt 
SSLCertificateKeyFile conf/ssl/web.key 
</VirtualHost> 

This virtualhost will then take care for all request arriving to port 81, and will always use the HTTPS protocol. So if you go to [example.com:81...] you get the same thing as when you go to [secure.example.com:81...]

[blasto]

the sole purpose of messing with proxy is to "firewall" enable my system. outside my network most probably 80 and 443 are the only port numbers available for outgoing http connections. so if my https is bound to 81 it would be unreachable. to sum up I'm trying to justify my "illegal" ports as sub.names like :

secure.example.com means port81
webmail.example.com means port82

I'll try ipbased config. I hope I can reach somewhere that way. thanks for your helps

[blasto]

seems like its impossible with apache to capture http traffic from port 80 encrypt it and route to another port (or ip)..

[gergoe]

Well, I did a little experiment myself with proxying SSL connections (never did myself for an oblivious reason, see below) through the http protocol, and you were on the right track, but;

What is the use of configuring SSL support for any website, and then making it unavailable for people with ports 81, and 82 blocked? And to solve it, you force a secured connection into the http protocol which is not secured? So actually what you seem to go for is to secure the communication between your Apache instance and a server next to it (or even on the same server), but the data between your Apache and your browser will go unsecured? If that's so, I'd drop the SSL completely, unless it is running on port 443.

Back to your virtualhost configuration, it looks quite okay, except one thing, the

ProxyPreserveHost On

declaration, which is meant to pass on the original Host header to the remote host, may lead to undesired results in your case.

[blasto]

you are right it looks like alittle awkward; I've been using ssl to encrypt the login data, to protect it against sniffing. till now its been working on standart 443. lately most of the firewall setups are blocking traffic on ports other than 21,25,80,443 etc. meaning that I'm stuck with a couple of ports and a bunch of services to squeeze in them.
from outside world we must be able to login to our website and connect our desktops via rdp; with proxying I tried to free up 443 for rdp connections and route the website login ecryption to another port. but soon discovered that(as you have said) if the first conn. is initiated from 80 (http) then its meaningless trying to encrypt it because it'll be passing the critical path in plain text.
now I lost my chance on ssl, I think I'll look for php encryption routines (if there is smth. like that) for the login. or I'll buy another ip address and split services over them.

[gergoe]

Of course it exists, this problem is quite common, this search [google.com] will put you on the right track. I could give you some more hints on this topic, but not on this forum anymore :-)