[38062] in North American Network Operators' Group
Re: VPN Solution (WAS: ORBS (Re: Scanning))
daemon@ATHENA.MIT.EDU (Jeremy T. Bouse)
Mon May 28 02:19:28 2001
From: "Jeremy T. Bouse" <undrgrid@Toons.UnderGrid.net>
Date: Sun, 27 May 2001 23:16:57 -0700
To: nanog@nanog.org
Message-ID: <20010527231657.A32560@UnderGrid.net>
Mail-Followup-To: undrgrid, nanog@nanog.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s"
Content-Disposition: inline
In-Reply-To: <5.0.2.1.2.20010528011249.02c05ea8@127.0.0.1>; from patrick@ianai.net on Mon, May 28, 2001 at 01:24:58AM -0400
Errors-To: owner-nanog-outgoing@merit.edu
--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I've not had experience with MS PPTP or Bay Networks but have worked
with the Sonicwall VPN client and FreeS/WAN and both only routed traffic
through the tunnel if it was destined for that end-point and left all other
traffic to traverse the network as it would be without the VPN tunnel. Both
of these solutions can manage this as they both actually modify the routing
table to include a route to the end-point over the tunnel and leave the
default route as is.
Jeremy
Patrick W. Gilmore was said to been seen saying:
>=20
> At 06:58 PM 5/27/2001 -0700, Owen DeLong wrote:
>=20
> >Roaming staff usually needs some form of VPN access, anyway, and even if
> >they don't, this is a great use for one. Put a VPN client on the roame=
r's
> >computer (Linux, Mac, and Windows 9x/NT/ME/2k all have IPSEC capable cl=
ients
> >available), then use the VPN to get back to the mail relay. If the mail
> >relay is behind the VPN tunnel termination point at the server end, then
> >it should only accept mail for relay from valid VPN clients. As such,
> >you solve the roaming staff problem without an open relay. VPN boxes
> >like Ravlin and Nokia Crypto Cluster are cheap enough today that I would
> >consider it a valid cost of doing business if you don't have a better
> >solution.
>=20
> I have an "operational" question. (SURPRISE! :)
>=20
> VPN solutions are getting inexpensive. However, they are sometimes far=
=20
> from optimal.
>=20
> The VPN solutions I have used (e.g. Bay Networks, MS PPTP) send *every*=
=20
> packet from the end user machine to the VPN end-point, not just selected=
=20
> packets (like with SSH tunneling).
>=20
> This can cause extremely poor performance for some roaming users. For=20
> instance, someone in Sydney with a home office in New York trying to get =
to=20
> a Sydney web server suddenly has to make two round trips to New York, jus=
t=20
> to cross town. Considering trans-pacific fiber congestion and other=20
> problems, this can make the VPN nearly unusable.
>=20
> Of course, you could tell the user to turn off the VPN, but you try to=20
> explain to a typical end user when he should and should not have the VPN=
=20
> turned on, or that he cannot send mail while browsing the web, or things=
=20
> like that.
>=20
>=20
> So, does anyone know of a VPN that does selective forwarding like SSH=20
> tunneling?
>=20
>=20
> >Owen
>=20
> TTFN,
> patrick
>=20
--=20
,--------------------------------------------------------------------------=
---,
|Jeremy T. Bouse, CCNA - UnderGrid Network Services, LLC - www.UnderGrid.n=
et |
| Public PGP/GPG key available through http://wwwkeys.us.pgp.net =
|
| If received unsigned (without requesting as such) DO NOT trust it! =
|
| Jeremy.Bouse@UnderGrid.net - NIC Whois: JB5713 - jbouse@Debian.or=
g |
`--------------------------------------------------------------------------=
---'
--SLDf9lqlvOQaIe6s
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7Ee1ZIcJXVD3J+UYRAqKyAKCUXeUJ1o+UKKj0qzc/J2mTN+jIKQCfUPzd
IUhKtG4PDqrk6mpD8QluZn8=
=93kt
-----END PGP SIGNATURE-----
--SLDf9lqlvOQaIe6s--
