[VPN] Service Provider based IPSec VPN services

Siddhartha Jain losttoy2000 at yahoo.co.uk
Fri Sep 13 02:38:29 EDT 2002


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. :)


 --- Chris Carlson <carlsonmail at yahoo.com> wrote: > Hi
Siddhartha,
> 
> All good questions!  I ran the security products
> group
> at a number of ISPs (as well as security consulting
> for enterprises) so I can help you here.
> 
> 
> > 1. Can I provide the service over the same link on
> > which I am providing internet services to the
> > customer?
> 
> Yes, you can depending on what vendor's VPN
> equipment
> you use.  Most VPN devices support "split-tunneling"
> which means that they can encrypt data that is
> destined for other locations on the VPN, but allow
> unencrypted traffic to the general Internet.
> 
> While some consider split-tunnelling to be a
> security
> threat (attackers from the Internet might infect
> internal machines and "ride" the VPN back to the
> headquarters or other locations), there is often a
> networking/business driver that forces
> split-tunneling: all traffic destined for the
> Internet
> doesn't have to be backhauled through the VPN to the
> HQ location to go out to the Internet, which
> relieves
> congestion on the HQ's links.
> 
> 
> > 2. I am aiming at installing no specialized VPN
> > equipment at the client location.
> 
> Good thought, since it's often difficult to maintain
> equipment at customer locations that you don't
> directly control.  Plus it gets really expensive to
> roll out a dedicated VPN device for each customer. 
> BUT, this creates a new set of issues, i.e. how do
> you
> effectively do network-based VPNs with some of the
> issues you highlight below.
> 
> Also, be aware that most every Internet connection
> requires a router (to terminate the T-1/E-1, DSL,
> Frame, etc.) and most routers nowadays have some
> type
> of IPSec-VPN software available.  So it is possible
> to
> offer a managed CPE-based VPN with an extra VPN
> device, just manage the VPN configurations on the
> customer router!
> 
> 
> > 3. The IP addressing of the client network is
> > obviously not under my control.
> 
> Correct.  With not many public IP addresses
> available,
> this means the the customer will be doing NAT at
> their
> border router.  And oftentimes, either the VPN
> devices
> is also doing NAT or the VPN devices is inside the
> NAT
> device.
> 
> And it's very difficult to terminate VPN sessions
> outside the NAT device because then you have to
> create
> a whole set of NAT mappings to access internal
> resources, a huge pain I urge you to NOT undertake!
> 
> If you wish to support IPSec VPNs in the service
> provider network, you need to do IPSec and NAT
> services on the same device, and there's only few
> system that can do this with multiple customers on
> one
> device: CoSine, Lucent Spring Tide, Nortel Shasta,
> NetScreen has a virtual router option, but these
> guys
> are very expensive.  And it's very expensive to put
> dedicated VPN devices in your POP just to do
> network-based IPSec VPNs.
> 
> Which leads us to...
> 
> 
> > Do you think, given these constraints, I can
> deploy
> > IPSec VPN? Or do you think in such a case, MPLS is
> > the best solution?
> 
> Ta-da!  Most service providers are looking at MPLS
> to
> do network-based (unencrypted) VPNs.  No specialized
> equipment is necessary at the customer premise,
> their
> existing network infrastructure can support
> MPLS-VPNs
> usually with a code update, the MPLS implemenetation
> of most vendors (notably Cisco VRF and Redback
> contexts) supports overlapping private IP address
> spaces and can do NAT.  The Cisco VRF feature can
> even
> map a Layer 2 VRF to an IPSec tunnel.
> 
> 
> If you have more detailed information on what you're
> trying to do, I can be more specific.
> 
> Also, I'm available for consulting, too, with
> reasonable rates!  :-)
> 
> Good luck to you!
> 
> Chris
> 
> 
> > TIA,
> > 
> > Siddhartha
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com



More information about the VPN mailing list