How to manage VPNs and ISPs

[spidey07]

We've been rolling out quite a lot of LAN-to-LAN VPNs here the past few years. I think the number is up to 25 now (maybe 1500 dialup). I'd like to throw out my biggest headaches and see if anybody's has a better way of accomplishing the same goal. That goal is "provide fast and reliable IP connectivity to international LAN sites or rural areas because Frame-Relay is too expensive."

1) How in the world do you manage all these differnt ISPs? I can't find two or three ISPs that have coverage on a global scale and have the same difficulty here domestically. Does anyone see an advantage to using an ISP that provides VPNs as well?

2) I normally use two way NAT on each side of the LAN-LAN VPN tunnel however this presents problems because I am forced to use static routes to reach the far-end LAN. Is there a better more scalable approach to addressing VPNs?

As far as the VPN equipment we use Ravlin and Nortel Extranet VPN concentrators. Consider the Ravlin a VPN appliance. One large one at headquarters and smaller ones at the LAN sites.

Any word of wisdom would be a great help. I can't continue to use a different ISP for each site, this is a billing and management nightmare. I use UUNET and Cable&Wireless as primaries and then am forced to find "Mom&Pops internet service" for the place they don't reach due to cost constraints. We are not a service provider this is striclty enterprise.

Thanks bunches,
spidey

 

[CTR]

1. As a Service Provider, I can tell you that you don't want Service Providers managing your VPN. Keep us blind and out of the loop. Any SP, no matter how big, will eventually let you down in terms of coverage. And then you are stuck with worrying about the SP's that ARE managing your VPN's as well as having to manage your own VPN's in other cases. Also, a SP providing VPN will probably be aggregating your traffic into their shared infrastructure, so any little slipup on their side (when does this NOT happen?) can open your VPN up to a world of sh!t. I think keeping it all in-house is the only thing close to scalable.

2. What type of tunnelling are you using? Maybe we can get around this NAT limitation. That would make your routing tons easier.

 

[spidey07]

1) That's what I thought. too bad. We've all struggled with different providers but being global puts it in a whole new category.

2) It is a plain jane IPsec tunnel with RADIUS authentication, full frame encasapsulation

Read from left to right, head quarters to remote LAN
Core---RavlinA---RTR---spa---I---spb---RTR---RavlinB---RLAN

Sometimes there is no NAT and the RLAN is a public IP address (I inhereited this part.) In which case the CORE needs a static route to RLAN, RLAN just has default. Sometimes there is NAT with RFC1918 addresses, problem there being some of our partners use the same addresses and I have to figure out the connectivity. I can probably get one of my engineers to fix this but I'd rather come up with the scalable solution first.

Catch my drift? Frames sourced from RLAN are encapsulated then delivered to RavlinA, where they are unencapsulated. At this point the sourceIP is public address. Core needs to know how to get back so hence the static route. Ideally I guess the RAVLIN could do a one-to-one NAT per Tunnell and then I'd only need a single /22 summary route for this pool. Treat it like one big dial-up pool.

The necessity is SCALE. We're trying to roll out firewall/VPN appliances for hundreds of employees with broadband to access HQ. I am not putting a static route for a single host(pc). I've never smoked that much crack. Again NAT is the answer, but how? I still need the ability to poll these home firewall/VPN devices with OpenView and also receive syslog.

thanks CTR.

 

[CTR]

You can't get much simpler than IPSec, so I like that part.

Would you consider source-routing this vpn traffic? If not then the multiple-tunnel/one-to-one NAT with a summary route would be a good solution, if your ravlins can handle that.

As for the home users -- would it be better for you if they opened a tunnel to the core, or to the remote office...it's a valid question! Also, can run something simple like RIP (or your favorite -- OSPF!) between the user and your corp. lan? Then redistribute those routes into your core routing protocol. If you kept this within the IPSec, it should be pretty secure.

Just throwing some ideas out...hopefully somebody smart will chime in any minute now. I'm running low on beer and cocktail napkins!

 

[spidey07]

Thanks for the tips CTR. The big problem is addressing. I'm trying to come up with an end all be all VPN solution that focuses on scale and ease of managment/adminstration (the more work I can push to NOC/Level 2 the better.

I know I'm not alone in this quest. Support LAN-LAN VPNs (dozens) and support 1000s plus dial up + broadband employees all managing to meld well with security and addressing. I'm not a service provider but our IT department in a sense is one. We supply information services to partners, subsideraries (sp?), and employees. I make decisions weekly on how many full time employees is the new product going to take. This crap is not that complicated but how can I build an infrastructre that can handle and grow this disparate set of applications? If I'm up the creek on the ISPs having differnet coverage then fine, but there has got to be a way to deal with the addressing. We're looking at the SonicWall firewall/VPN appliance for the broadband employees and it is very powerfull. But the second the engineer came to me and said "We need more static routes to make this work" He already knew my response..."You're smokin crack, find a better way."

Making it work is easy...turning it into a revenue generating/easy to support/totally manageble product is another story.

Any other ideas?
I'm still thinking the large summary route pointing to the VPN concentrator is nice. What do you mean by source routing CTR? Making routing decisions based on source address a.k.a route maps?

Big problem with NAT...it normally only works one way. I need it to work in both directions. Yeah, you can talk about port forwarding (a.k.a static NAT) but this does not help my particular situation as there are at least a hundred hosts in the data center that need reachability from remote VPN clients. I am NOT manually configuring static NATs for applications that can change IP hosts at any time. Again...crack pipe not needed.

spidey

ps - Yes, Core is the intended destination for all VPN traffic/tunnels as all applications are hosted here. Our traffic is either data center or internet (www, email, B2B) bound.

 

[Shuxclams]

Could Another soloution would be Terminal server and/or Citrix overlay. That way the connection would be up to the client and no need for monitoring or service of the "Bad VPN's", that is of course only useful if its applications they need.







SHUX

 

[CTR]

Spidey07:

Yes on the source-routing. Route maps are one way to do it, if you have the architecture to support it. But I am assuming you will want to put a router between your core and the VPN aggregator to handle this. We've used policy-based routing to accomplish this in the past, but you take a big performace hit on Cisco gear with that. So a dedicated router is the only way to make it effective and SCALABLE (your new favorite word, it seems). The concept I'm trying to push is a segmented VPN area of your network, with only one ing/egr to your core, controlled by what is effectively a policy router. What's keeping you from removing the NAT once you get the traffic tunneled and IPSec'ed (new verb)? You'll have to tighten up security at the remote router, and the "policy router" I mentioned, but it is perhaps worth some consideration? You can then distribute routes to your core for your remote "private number" networks. Does that make any sense at all? I might get smarter this afternoon...still just throwing out the first ideas that pop into my head.

Where's Damaged? I KNOW he has something to add here.

 

[CTR]

Oh and the dialup vpn users you mentioned in your first post...you just need to get a local provider that will configure their equipment for L2TP back to your LNS. I do it all the time for our wholesale customers as well as our internal VPN.

 

[Damaged]

CTR. I'm here and reading. Not much to say though as I only know VPN in theory. Never messed with it much in application.

I too work for an SP (an ISP to be exact) but what I deal with are NASes, routers, and switches. I don't tend to do much design...yet. Given that, I keep my mouth shut on things which I'm not well versed.

All I really care about is preventing end users from injecting crap into our network (i.e. RIP, OSPF, BGP, and a few other things). Heck, I filter off NETBEUI/NETBIOS traffic unless a dedicated user specifially requests those ports open. You want to set up a tunnel? I don't care about that. Doesn't affect "me" in the least.

I agree that you want the SP involved in managing that part of your network as little as possible. Now...iffin' I could only convince some of my superiors of that <sigh>. They want to sell/config/maintain end user firewalls now. I'm not real keen on that. Mostly for liability reasons. Que sera, sera.

 

[spidey07]

CTR, yeah it all makes sense and that kind of approach is what I'm leaning toward. Currently we do have a &quot;VPN zone&quot; in the infrastructure. Basically there is a high performance core with a few access blocks attached to that (VPN, Internet Infrastructure, Partner/Customer Access, WAN) The VPN and Internet blocks virtually parallel each other with the firewall going directly into the core.

I'm going to try to work out the addressing. I like the policy router idea as I can handle routing and access from a single point just like I did the the Partner 7000. A 3600 should have plenty of processor for the task including any route maps/access lists. Need to do more work on the capabilities of the Ravlins though. I really want the entire VPN block to be summarized with a single statement. That way it will SCALE better.

had to take a stab back at ya &quot;source route&quot; boy

keep ya posted.

 

[Vegito]

I got a PPTP question for you guys..

NT 4 Server Running RRAS. In Private Network Address Space, 192.168.1.x
Mapped statically to a legal IP address

Any Win9X/NT4/2000 Pro/Notebook/Desktop outside can VPN into it and gain full access.

I have 1 desktop that is unable to connect successfully...

W2K Pro Client, standard config.
It's able to connect to the server and ping the server but not anything else, so it can ping the 192.168.1.x but nothing else.

I tried the same setting but I can always access other machines pass the PPTP server.

Any one have any idea ?

Also machines behind the pptp can ping everybody VPN in but not that 1 machine that is VPN in..