--1aa3fXZUP8Xb8QnO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 14, 2005 at 12:34:24PM +0100, Stephen Borrill wrote:
> The problem here is also that the client/customer is a separate entity=20
> from the firewall people.

Even if they are cluless, and even if they are wrong, you want to
consider carefully the ramifications of deliberately bypassing or
playing subterfuge against folks who, for better or worse, are
legitimately responsible for network security issues.

> >You make the remote clients connect from a given source port (range)
> >that the server nat can recognise and direct appropriately.
>=20
> Yes, that might work to allow us OpenVPN access while retaining https for=
=20
> everyone else.

I didn't say so before, but obviously you would be best to use a low
source-port, outside the ephemeral range a browser would use, to avoid
conflicts. =20

And, of course, you can use NAT on the client side to make it appear
to come from this source port, if you have the opportunity and/or if
the client vpn software won't cooperate easily.

> >Or you make the client somewhat http aware, so that it connects to a
> >server running as a web app.
>=20
> I don't think that's possible in this case.

Ok.

Yet another option is to have a trigger webpage that the user taps on,
and then the very *next* session from that IP gets sent elsewhere.

> The OpenVPN chaps determined that the SSL streams can be identified from=
=20
> the first couple of bytes and then passed on to the appropriate service=
=20

Ah, I see.  That sounds like there's a particular identifier in the
SSL negotiation.  Examine this carefully with ssldump, and if you can
find something that reliably identifies the desired traffic, you could
incorporate this into an ipf proxy that assigns NAT accordingly.

One of the problems with this is that, by the time you've seen the
data in question, TCP is already established, so you need to be a more
active proxy (like your netcat suggestion).

> Citrix Secure Gateway is an SSL VPN that runs on Windows and can port=20
> share with IIS in just the fashion we want to achieve.

I hate that product, especially because Citrix salespeople mispromote
it as a way to get around suitable firewall administration.

> We want to use NetBSD as much as possible though. :-)

That I can applaud :)

--
Dan.
--1aa3fXZUP8Xb8QnO
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFChvsgEAVxvV4N66cRAoGEAKCxmu5Nsg83G6FruOfI9hTC2xJGgQCdEqM8
qzaYSNE4XlcRkK/F0epGd7s=
=L6fB
-----END PGP SIGNATURE-----

--1aa3fXZUP8Xb8QnO--