[VPN] Service Provider based IPSec VPN services

Chris Carlson carlsonmail at yahoo.com
Fri Sep 13 11:21:52 EDT 2002


Hi Siddhartha,

You sent this email to the VPN group, so I'll reply to
all as well.  We'll hold off on that job discussion
just yet.  :-)

One thing to keep in mind, though, is that
corporations might wish to keep their own internal IP
addresses even for remote users, the benefit of IPSec
Tunnel mode of some VPN vendors, where you have an
"outer" IP address which is your public ISP IP address
and an "inner" IP address which is from a subnet on
the enterprise side.

This "inner" address might be a RFC1918 private IP, or
as I recommend to my clients, be a dedicated remote
user subnet, assigned to specifically keep track of
remote users accessing internal systems.

For example, if a company assigns 172.30.0.0 to be the
remote user subnet, a quick look or query to ANY
internal system/server would see when 172.30.0.0
addresses accessed them.  Great for security audits!

But going back to Kent's comments (and others): what
is good for the service provider might not be good for
the enterprise.  What customer problem are you trying
to solve?  Network reach, cost, management,
monitoring, etc.?

I *dislike* SPs pitching MPLS services as VPN, since
from my viewpoint the P meaning Private is encryption.
 I don't think ANYONE considered Frame or ATM to be
private, just Virtual, hence instead of a VPN it's a
VN!

Having said that, many SPs are in fact positioning
MPLS connections as a low-cost alternative to Frame
and ATM.  If they want security and encryption, then
CPE-based IPSec can be used (even used THROUGH the
MPLS connection if you're doing Traffic Engineering).


The other disadvantage of MPLS is what do you do if
the customer has offices that are not servicable by
your network and have to use someone elses?  Now
you'll have to support CPE-based IPSec for
site-to-site VPNs.  So I believe that you need to
support a hybrid even in site-to-site.

What VPN concentrator are you using?  Some newer ones
might be able to map private IPs on a per-customer (or
per-tunnel) basis.

The other bad point about remote user VPNs from a
service model is handling the remote user client. 
That can be a pain and chore on a wide spread basis. 
Some companies offer this as a service to ISPs
directly, some vendors have thinner clients, some VPN
vendors are now supporting SSL-based VPNs (watch out,
some of these vendors only support web apps and file
sharing, not some native apps like Outlook yet!), and
some even do L2TP or L2F tunnelling from the dial
servers directly with no client needed (but then you
can do it from any Internet access point).

You really need to develop a true hybrid solution
spread across all access methods (off-net and on-net),
across all VPN types (site-to-site, remote user,
extranet), and across all technologies (IPSec, MPLS,
SSL, etc.) with ALL of that leveraged by a single
unifed back-office function: provisioning, mgmt, offer
management, authentication (even customer-internal
auth servers), reporting, alerting, support,
operations, etc.!

A BIG chore that no one has solved yet!  In most
cases, SPs just deploy CPE-based IPSec boxes that can
pull triple duty: on-net site-to-site IPSec, off-net
site-to-site IPsec, and remote user IPSec VPNs with
internal auths.

And position MPLS has a frame alternative for on-net
customers only!

I'd gladly put together a consulting engagement to
help you through this (read $$$s) and bring in some
other smart people (Kent Dallas, are you listening?)
:-)

Comments anyone?

Chris
--

--- Siddhartha Jain <losttoy2000 at yahoo.co.uk> wrote:
> Hi Chris,
> 
> Thanks for your input and sorry for rpelying late. I
> have come out with a solution which is a hybrid of
> MPLS and IPSec.
> 
> The brief is that all site to site VPN is handled by
> MPLS. Roaming users connect to a VPN concentrator
> using IPSec. Each corporate group is allocated a
> chunk
> of IPs for its romaing users. From the concentrator
> the traffic needs to be routed to the appropriate
> MPLS
> tunnel corresponding to the corporate customer. I am
> gain replying on MPLS to do this.
> 
> So, user A, dials to the internet and gets
> authenticated and connected to the VPN concentrator.
> He gets an IP, say 202.54.3.1, which is an IP from
> the
> chunk of IPs (say 202.54.3.1-64) allocated to that
> corporate for its roaming users. The VPN device
> connects to the same layer-3 device which takes care
> of site-to-site MPLS VPN. Now when the user connects
> to the VPN device over internet, the layer-3 device
> sees an IP (202.54.3.1) coming on its interface
> which
> is connected to the VPN device. The layer-3 switch
> *knows* that the particular IP address belongs to
> customer A and hence tags (using MPLS) the packet
> and
> sends it to the appropriate interface which connects
> to the customer A's router.
> 
> Need to run the whole thingy thru' the local Cisco
> guru. Once that is done, maybe I can share the doc
> with this group too. :)
> 
> How does the solution sound? Got a better idea?
> 
> Regards,
> 
> Siddhartha
> 
> PS. Got a job for me?? ;) Willing to relocate to any
> part of the world. :)
> 
>

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com



More information about the VPN mailing list