Category: IPsec
L2TP: The revenge of hardware switching
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.
Follow-up: P-to-P router encryption
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:
Encrypting P-to-P-router traffic
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).
GRE Keepalives or EIGRP Hellos?
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 politically correct answer is »use GRE keepalives and keep EIGRP hellos at their default values«. Even better, use BFD over GRE (if your device supports it) instead of a hodgepodge of point technologies.
Fat finger follow-up: use the key labels
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
rsakeypair VPN