On Sat, 14 May 2005, Daniel Carosone wrote:

> On Sat, May 14, 2005 at 11:36:19AM +0200, Ignatios Souvatzis wrote:
>> On Sat, May 14, 2005 at 11:31:22AM +0200, Ignatios Souvatzis wrote:
>>> 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.
>>
>> Here I assume that your machine is the only remote OpenVPN endpoint. I
>> just realized that maybe you're using OpenVPN to connect road warriors?
>>
>> In that case, this wouldn't work.

Both OpenVPN and https may want to be accessed from anywhere, by the 
clueless.

The problem here is also that the client/customer is a separate entity 
from the firewall people. For the record, we supply NetBSD servers to 
schools throughout the UK that we need to remotely administer (many of the 
schools do not have the time, skills or inclination). We are also Citrix 
partners, so we need to support multiple Citrix servers on their sites 
too. Schools in the UK are nowadays generally connected to giant WANs on 
private IP ranges run by broadband consortia which have varying opinions 
on remote access and security. Some are happy to map through an external 
real IP address on a list of ports. However, the more braindead ones say 
this isn't possible for bogus security reasons (e.g. http is intrinsically 
insecure and would allow a network to be hacked into. Or you must use a 
Cisco VPN with Xauth and group passwords :-/ ).  In this case they can 
have 1 external address with TCP port 443 forwarded to an internal 
address. They will not move on this. We have to be clever and work around 
the limitations while allowing our customers to get the most out of what 
we supply.

> You make the remote clients connect from a given source port (range)
> that the server nat can recognise and direct appropriately.

Yes, that might work to allow us OpenVPN access while retaining https for 
everyone else.

> Or you make the client somewhat http aware, so that it connects to a
> server running as a web app.

I don't think that's possible in this case.

The OpenVPN chaps determined that the SSL streams can be identified from 
the first couple of bytes and then passed on to the appropriate service (I 
guess netcat could be hacked to do this, but it's another application in 
the loop).

Citrix Secure Gateway is an SSL VPN that runs on Windows and can port 
share with IIS in just the fashion we want to achieve. We want to use 
NetBSD as much as possible though. :-)

-- 
Stephen