Subject: Re: Port sharing?
To: Daniel Carosone <email@example.com>
From: Stephen Borrill <firstname.lastname@example.org>
Date: 05/14/2005 12:34:24
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
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
> 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
> 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
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. :-)