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.
In short, a reasonable (although a bit kludgy) design that has been working for years on a 7200-series router is impossible to implement on an ASR 1000.
Before you start bashing Cisco, remember that ASR implements most of the packet forwarding process in hardware. While it’s very simple to stack together numerous randomly-selected features in a software implementation, it’s hard to do the same on a streamlined hardware platform.
Developing custom hardware is also way more expensive than writing a few more lines of C code. When designing a hardware implementation, one is thus temped to implement only the most commonly used combinations of features (or the features used by the biggest customers). If you happen to be relying on a rarely used set of features, you’re bound to have interesting problems.
With this in mind, it looks like you have only two options when deploying a device with hardware-assisted switching:
Minimize the number of features used by the device to an absolute minimum. This is not always a realistic option as you might be forced to increase the device count in your network (ASRs could be successfully deployed in our sample network if you’re willing to split L2TP termination and IPSec termination). You’re also left wondering why you’ve paid the premium for all the features you can’t use concurrently.
Work with someone who understands the device’s caveats and restrictions. If you’ve just started deploying new hardware in your network, you cannot be expected to know all its intricacies (although I’m positive your PHB thinks otherwise). Make heavy use of people who have done a similar job before. Engage Cisco’s Professional Services or a highly knowledgeable system integration partner (I wouldn’t even try to use resellers competing solely on low prices) that has extensive in-house lab facility (so they could stress-test the design before implementing it in your network).
i can add that ZBF with zone-pair in VRFs is also not working, same goes for NAT with VASI iface.
concerning VRF-aware L2TP, which hardware/software version are you using? i've been successful with it!
cheers, henrique
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_vrf_aware_ipsec.html
I use it only for a single static point-to-point tunnel, so it's not very complex. However, it looks like it works for dynamic virtual template interfaces. Was there perhaps something specific that didn't work?
The twist was that there are two sets of networks that must be routed across the virtual link to the remote side. I'll call them "SecureLAN" and "InsecureLAN." These networks exist at both sites, and each LAN is separated by a firewall at each site.
The routes distributed by the IGP within "InsecureLAN" and "SecureLAN" overlap with each other. Moreover, "InsecureLAN" must carry a default route through the virtual WAN link to the remote side.
What I did, instead of using two pairs of routers for each network, was to configure a pair of 3825 routers with two named VRF instances. One named VRF was used for the InsecureLAN, and another named VRF, "Inet", was used for the Internet-facing interface. SecureLAN was connected to the routers' global VRF.
IPsec operates within the "Inet" VRF only.
The reason I decided to create a named VRF for the Internet-facing LAN connection, and to use VRF-aware IPsec, is very similar to the reason you gave in your earlier post: It is much easier to manage and administer the router within the global VRF. Also, at deployment time, I believe there were some needed management options that were not VRF-aware in that IOS rev.
To finish talking about the design, two GRE tunnel interfaces are set up on each router, one for "InsecureLAN" and one for "SecureLAN." The IP address endpoints are the same for each tunnel interface; GRE keying is used to differentiate each tunnel.
do you know if this L2TP/IPsec and VRF interop issue is still there in latest IOS-XE ?
Thanks
https://tools.cisco.com/bugsearch/bug/CSCur76833/?referring_site=bugquickviewredir
ip access-list extended L2TP_INSIDE_VRF_OMIT_NAT
deny ip MY_LT2P_NETWORK/27 MY_PRIVATE_NETWORKS/24 //deny NAT to private network(s)
permit ip MY_LT2P_NETWORK/27 any //allow 0.0.0.0 to the internet
permit ip MY_VRF_INSIDE_NETWORK/24 any //allow VRF network access to 0.0.0.0
deny ip any any
route-map L2TP_INSIDE_VRF_OMIT_NAT_ISP1 permit 10
match ip address L2TP_INSIDE_VRF_OMIT_NAT
match interface GigabitEthernet0/0/1
ip nat inside source route-map L2TP_INSIDE_VRF_OMIT_NAT_ISP1 interface GigabitEthernet0/0/1 vrf INSIDE