Small Steps to Large Complexity

Imagine you have a large retail network: your remote offices use ISDN to dial into the central site and upload/download whatever periodic reports they have. Having a core router connected to an ISDN PRI interface is the perfect solution:

A few years later, ISDN is becoming too slow for your increased traffic needs and you want to replace it with DSL or VPN-over-Internet solution. Your Service Provider offers you PPPoE forwarding with L2TP. This is a perfect solution as it allows you to minimize the changes:

  • ISDN BRI is replaced with PPPoE in remote offices. No other configuration needs to be changed if you’ve already used dialer interfaces.
  • ISDN PRI is replaced with vpdn-group in your LNS. No other changes are needed if you’ve already used virtual templates.

Since the traffic from remote offices reaches the central site through its Internet link, it’s prudent to implement IPSec encryption of sensitive traffic (although it’s unlikely anyone would snoop the L2TP traffic between LAC and LNS).

There’s almost no change in your connectivity requirements: instead of having an ISDN PRI and a LAN interface, the LNS router now has two IP-enabled interfaces: one toward the Internet and another one into your network core.

You could connect the LNS router to your firewall, but that would require major redesign of your firewall policies. It’s simpler (but still relatively secure) to connect the outside LAN interface of the LNS router to the Internet and the inside LAN interface to the core network; a strict access list on the outside interface blocks all incoming traffic but the L2TP packets.

So far so good… but here’s a catch: as you don’t know the public IP addresses of the L2TP NAS (LAC in the above picture), the LNS router needs a default route pointing toward the Internet. It also needs a default route toward the core network; otherwise the traffic from remote offices to the Internet would not go through the firewall.

Assuming that you want to minimize the changes to your design, what would be your solution to this problem?

8 comments:

  1. Hi there,

    Long time reader but first time poster. I'm a bit of a novice and thought I'd take a stab at this. Could you apply a route-map to each of the interfaces on the LNS router with no match statement, and make it set the exit interface to the opposite interface? You wouldn't need to know any addresses, just interfaces.

    Ian.
  2. You could set the default route on the LNS pointing towards the LACs and forward all traffic coming with a branch source ip address to the next-hop of the core router by using policy routing
  3. Option 1) use PBR on the virtual-template interface with set ip default next-hop pointing to the internal router or
    Option 2) put the inside interface and virtual-template in a VRF or
    Option 3) ask the SP if they can announce their LAC IP addresses with BGP so that we do not need a static default route for reaching the LACs

    I prefer option 1
  4. Hi! I don't use L2TP in my network but I have somewhat similar setup with DMVPN, where SP provides IP connectivity from spokes to hub within SP's network and Internet access is being router centrally via a firewall. I was posed with the same question, which way the default route should be pointed, since spokes' addresses are dynamic.
    So I resolved this with the following configuration at hub:
    crypto dynamic-map [SP-DMVPN map name] 10
    set transform-set [DMVPN TS name]
    reverse-route remote-peer [next hop at SP's side] gateway
    interface GigabitEthernet0/0.2
    description SP tunnel termination
    ip address [SP provided address]
    service-policy output [SP-DMVPN map name]
    0/0 route is being received by this router via OSPF and points to the campus core network.

    Now when spokes dynamically establish IPSec with hub, crypto subsystem adds static routes pointing to their Internet IPs via hub's SP-facing interface:

    tunnelhub#sh crypto route

    VPN Routing Table: Shows RRI and VTI created routes
    Codes: RRI - Reverse-Route, VTI- Virtual Tunnel Interface
    S - Static Map ACLs

    Routes created in table GLOBAL DEFAULT
    [spoke SP IP]/255.255.255.255 [1/0] via [hub SP nexthop] tag 0
    on GigabitEthernet0/0.2 RRI

    I'm really not sure if this is applicable for L2TP, anyway, maybe someone would find this hint useful.
  5. I would look into establishing a separate VRF for the internal interfaces of the LNS router, specifically the internal Ethernet interface and the Virtual-Template interface.

    One could also put the external interface in a VRF, but that is more complex and may not be supported in PPPoE/L2TP. (I do know for a fact it is supported in recent versions of IOS' IPsec implementation.)

    Not having worked with PPPoE/L2TP, I couldn't tell you without research whether VRF-based separation would work.
  6. You can put the vpdn-group in vrf by using vpn command inside it and the interface of the LAC in that VRF
    Then you can route the default of the L2TP to the LAC inside the VRF and to the LAN outside the VRF
  7. I think asking the provider which LAC addresses they use would be the easiest way.
    Otherwise maybe some kind of an "outside LNS" (located in the internet) could be depolyed which accepts the sessions forwarded by the ISP's LAC and forwards them once again to an "inside LNS" (which is the already existing ISDN hub-router).
  8. Hi Ivan, where you get those cool routers, clouds, etc. symbols, icons or how you name it?
    Hidden Cisco icon packet?
    Software?
Add comment
Sidebar