On Sat, May 14, 2005 at 10:14:47AM +0100, Stephen Borrill wrote:
> On Sat, 14 May 2005, Ignatios Souvatzis wrote:
> >On Fri, May 13, 2005 at 05:16:49PM +0100, Stephen Borrill wrote:
> >>I'd like to be able to share port 443 between Apache+mod_ssl and OpenVPN
> >
> >Isn't OpenVPM  tunneled through UDP? How is it related to the http-ssl
> >tcp port, then?
> 
> Early versions only had UDP support, yes. TCP has been supported for a 
> long time now though. For people behind NAT, oddly configured firewalls 
> (that they have no administrative controls over) and so on, TCP is the way 
> to go. For the particular customer I have in mind here, only TCP 443 will 
> be opened by the firewall administrators.

Well, if you only have one IP+Protocol+port combination, how can you use
it for two purposes? Unless you want to put the web server into the VPN
address range, but I guess it's supposed to be publicly accessible.

I think the way to go is to put some enlightment into your client.
If they want two services, they have to somehow open two communication
channels. If you have to simulate them, the result will be more 
fragile than the clean solution.

You could use ipf+ipnat (at your customers site) to remap _your_
endpoint of the VPN server to an internal address/port that the OpenVPN
server listens to, and the all other external addresses to an internal
address/port that the httpd+ssl is listening to. The result would be that
the machine at your end of the VPN connection can't directly access your
client's httpd for testing or operational purposes.

Sorry, no ready-to-use recipe, but ipnat with, more or less, two "remap"
lines added should do the trick.

Of course, you could put the web server at some of _your_ addresses and
tunnel it through the VPN.

Both solutions add complexity to the firewall setup and make it more
vulnerable to misconfiguration etc., but the rope is there for your 
clients to hang themselves.

Regards,
	-is

(Ceterum censeo NAT esse delendum)