When developing the Choose the optimal VPN service webinar, I decided to test everything I was talking about in a lab (you wouldn’t believe how much misinformation is spread across the Internet) and ended up with several DMVPN scenarios that most people would consider to be somewhere between peculiar and outrageous.
The best one: DMVPN Phase III network with ODR between spokes and level-1 hubs and OSPF inside a hierarchy of hubs ... of course fully redundant all the way down to the spokes.
The webinar has been rescheduled to July 7th (Cisco Live is taking place from June 27th to July 1st).
The design scenarios were simply too god to be left to rot on my hard drive (some of them were screaming to be documented and talked about), so I organized them into a progressively evolving story described in the DMVPN: Advanced and crazy scenarios webinar.
If you’re a CCNP/CCIE-level engineer interested in DMVPN, I’m positive you’ll enjoy this webinar (click here to register) ... and I’ll try to serve you as many curveballs as I can manage to fit within two hours.
Arnold sent me an excellent question yesterday; he bought my Deploying Zone-Based Firewalls book, but found no sample configurations using IPSec VPN. I was able to find a few sample configurations on CCO, but none of them included the self zone. The truly interesting bit of the puzzle is the traffic being received or sent by the router (everything else is self-explanatory if you’ve read my book), so those configurations are not of great help.
Realizing that this is a bigger can of worms than I’ve expected, I immediately fixed the slides in my Choose the Optimal VPN Service webinar, which now includes the security models for GRE, VTI and DMVPN-based VPN services (you can still register for the May 12th event).
These last-second changes were included in the downloadable PDF materials that the registered attendees can already get from our Webex site.
Do you like the solutions to the L2TP default routing problem? If you do, the ASR 1000 definitely doesn’t share your opinion; so far it’s impossible to configure a working combination of L2TP, IPSec (described in the original post) and PBR or VRFs:
PBR on virtual templates: doesn’t work.
Virtual template interface in a VRF: IPSec termination in a VRF doesn’t work.
L2TP interface in a VRF: This one was closest to working. In some software releases IPSec started, but the L2TP code was not (fully?) VRF-aware, so the LNS-to-LAC packets used global routing table. In other software releases IPSec would not start.
Update (2010-05-03): Cisco VPN Client 5.0.07 has been released.
Regardless of the supposed focus of my blog, its most popular post still remains the Cisco VPN client in 64-bit Windows 7. This requirement is obviously so common that Cisco decided to implement the 64-bit client natively; it’s currently in beta testing. Philip Remaker left the following comment at my original post:
Majority of IT managers and enterprise network designers are somewhat confused by various VPN service offerings, from provider-delivered layer-2 and layer-3 VPN services to self-created IPSec VPN, SSL VPN, DMVPN and GETVPN.
The Choose the optimal VPN service presentation gives you a comprehensive overview of all major VPN technologies, their benefits and drawbacks as well as high-availability design guidelines.
This presentation is also available as an Internet-delivered webinar.
The “P-to-P router encryption” post has generated numerous comments. One of the readers suggested using dedicated Ethernet encryption devices, which is probably the best option if you’ve realized you need encryption in the network acquisition phase when there’s still some budget left (too bad the vendor recommended in the comments does not want to admit how expensive the boxes are).
However, assuming you have high-speed IPSec encryption modules and you have to implement P-to-P encryption in existing network, the only option left to you is GRE tunnel. Here’s why:
Rob sent me a really good question:
I have an enterprise MPLS network. Two P routers are connected via carrier point-to-point Gigabit Ethernet and I would like to encrypt the MPLS traffic traversing the GE link. The PE-routers don't have hardware crypto accelerators, so I would like to keep the MPLS within the buildings running in cleartext and only encrypt the inter-site (P-to-P) MPLS traffic.
The only solution I could imagine would nicely fit the motto of one of our engineers: »Any time you have a problem, use more GRE tunnels« (if you have a better solution, please post it in the comments).
It looks like everyone who’s not using DMVPN is running IPSec over GRE these days, resulting in interesting questions like »should IP use EIGRP hellos or GRE keepalives to detect path loss?«
Any dedicated link/path loss detection protocol should be preferred over tweaking routing protocol timers (at least in theory), so the PC answer is »use GRE keepalives and keep EIGRP hellos at their default values«.
BFD would be the perfect solution, but it's not working over GRE tunnels yet ... and based on its past deployment history in Cisco IOS years will pass before we'll have it on the platforms we usually deploy at remote sites.
I am wondering if there is a way to change routing preference from using one VPN link to another VPN link, and making this change only at one side (head end) of the bundled vpn's and have the traffic path still remain symmetric.
One of the solutions I’ve proposed (using BGP with weights and MED on the central router) worked really well for him.
If you have an interesting network-related problem, you might consider using NIL’s forums to ask NIL’s CCIEs for an opinion. If you’re new to BGP and would like to use it in your enterprise network, start with the BGP resource center in the CT3 wiki.
Boštjan Šuštar is continuing the Cisco IOS VPN saga, arriving at technology#5: GET VPN (he’s now on par with Arden Packeer’s “OSPF over Frame Relay” saga). In the April IP Corner article, he’s covering the GET VPN basics, design guidelines and implementation example.
Karsten Iwen made an interesting comment to my “Don't let a lab rat anywhere near a production box” post: you should avoid the SSH/VPN key generation mistakes by using key labels. He also wrote a post explaining the concept but since it’s in German, let me rephrase it in English.
Cisco IOS release 12.2(8)T added the label parameter to the crypto key generate rsa command. You can use this parameter to assign a label to your VPN key, for example
Rtr(config)#crypto key generate rsa label VPN modulus 2048
To use the labeled key to generate your certificate, use the rsakeypair command in the CA-trustpoint configuration mode:
crypto pki trustpoint example.com
enrollment retry count 100
enrollment mode ra
enrollment url http://ca.example.com/certsrv/mscep/mscep.dll
The fourth article in the IPSec series written by Boštjan Šuštar deals with Dynamic Multipoint VPN (DMVPN). Boštjan describes the design and implementation aspects of DMVPN without going into too many unnecessary details, behavior of RIP, OSPF and EIGRP over DMVPN clouds and the resilience (multiple hubs), performance and scalability considerations of DMVPN.
Let’s assume that you’re the manager of the internetworking team for a large enterprise network. You’ve just decided to migrate less-critical sites in your network from traditional (expensive) WAN offerings to IPSec running over the public Internet. Your internetworking architect has worked with the vendors to select the best technology and chose dynamic multipoint VPN (DMVPN) with a CA server running on a router. The proof-of-concept lab has been built and now you’re ready to order the new boxes and start the deployment. But there’s a major roadblock in this otherwise rosy scenario. Your engineers have to be trained on the new technology before the rollout; otherwise, you can expect interesting fallouts when the first problems inevitably start to appear.