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?
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.
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
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
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.
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.
Then you can route the default of the L2TP to the LAC inside the VRF and to the LAN outside the VRF
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).
Hidden Cisco icon packet?