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

12 comments:

  1. weeks ago i came to the same conclusion about this so called NG platform - ASR
    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
  2. I use IPsec termination in a VRF today, and it works well.

    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?
  3. VRF-aware L2TP is fine, it's just the combination with IPSec that doesn't work.
  4. What exactly are you doing?
  5. humm... interesting, i need run the same but with VASIrightx interface has a IPSec tunnel end point
  6. The overall goal was to provide a cheap backup route for inter-LAN connectivity between two sites. I use GRE-over-IPsec to provide the virtual WAN link.

    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.
  7. Perfectly sane ... but you're using 3825 routers, which are software switching platforms, so they can take almost any abuse you throw at them.
  8. Applying vrf to l2tp tunnels via radius seems to be a problem on the ASR's as well or is related. Once the vrf is set via the cisco avpairs the ipcp process stops and peers never get to learn/negotiate addresses. This has the effect that the tunnel addresses are not assigned and the framed routes are not placed in the vrf routing table.
  9. Hello Ivan,

    do you know if this L2TP/IPsec and VRF interop issue is still there in latest IOS-XE ?

    Thanks
    Replies
    1. No idea - this was written 5 years ago. Test it ;)
  10. L2TP/IPsec does not supported on ASR

    https://tools.cisco.com/bugsearch/bug/CSCur76833/?referring_site=bugquickviewredir
  11. I made L2TP/IPSEC work for VRFs on the 4451-X which has the same quantum flow architecture as the ASR. You must install an ACL to exclude your your VPN network from being NAT'd beforehand or you won't be able to ping anything other than an interface IP on directly connected interfaces and private networks derived by your VRF's IGP.

    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
Add comment
Sidebar