IPsec VPN IOS - ASA

Question

Hi,
I'm in the process of migrating some old IOS IPsec VPN configurations from IOS to ASA.
What immediately becomes a problem is that there is no way to virtualize the routing tables on a single ASA. The original IOS setups uses separate VRF:s for each customers and therefore overlapping LAN networks or even VPN pools aint a problem.
This has been in the past avoided (in other ASAs) by using default route for each customer interface on the ASA (with different metric). With this we can have overlapping LAN networks for the customer. Though the limit for the customer links become = metric value range. So basically even if we had an ASA with support for 1000 Vlans we still couldnt use this setup as we would run out of usable metric values for the default routes pointing to the customer links/networks.
So looking at the above situation it seems we would just need to have a load of ASAs with support for 250 Vlans handling each customer groups and not a single ASA which could handle all the VPNs (if theres more than the mentioned approx. 250)
Another option is I guess using a single link on the ASA for all the customer with a tunneled default route and handling the virtualisation on the core device by using PBR to route the packets to different VRF. This in turn would create alot of more configurations on the core device and a single VPN configuration/connection would become harder to manage.
Has anyone run into a similiar situation and how have you handled it? Have you moved to another device manufacturer or sticked with the IOS perhaps? Its unfortunate that the ASA can't handle this by itself.
- Jouni

Answer 1

Hi,
I've heard from our local Cisco contact that L2L VPN is coming. (Though in his words most people were waiting for Client VPN support, as were we) L2L VPN only provides minimal help to our situation as most connections are Client VPN.
Basically the ultimate goal is to eventually migrate all IPsec Client VPN users to start using AnyConnect.
The goal now is to get the old IPsec Client and L2L VPNs of the current device so we can remove the actual 6509/VPN/FWSM device from the network. (Because of the old hardware)
Even though we have newer IOS devices in our network we would rather keep the Client VPN off the IOS devices. So the idea was to quickly move the Client VPNs to ASA and L2L VPN to another IOS device (by moving the L2L VPN peer IP address to the newer IOS device along with the configurations)
We also started considering hosting the VPN services on a more high end device(s) which could support everything we need. In this case the ASA seemed a natural choice. Then again IOS gives alot more flexibility and the most important to us is the ability to virtualise routing.
I've read that AnyConnect VPN has also come to IOS devices.
Quick Google search gives this Cisco document
http://www.cisco.com/en/US/products/ps5855/products_configuration_example09186a0080af314a.shtml#intro
How is the AnyConnect on IOS compared to ASA? Would IOS devices at some point (or already?) become a viable option for hosting all the VPNs? (The use of AnyConnect and Clientless VPN has kept us away from continuing with IOS)
Also on another note, I guess I missed one thing when writing the original post.
I guess you can actually use specific routes on the ASA for the overlapping customer networks with different metrics (instead of the default routes with different metrics) This would enable you to handle the routing for more customer links than when simply using default routes towards each customer link with different metric. As now each network range could overlap on 255 customers.
Heres a small sample of a lab configuration of that kind of situation
interface GigabitEthernet0/0
description TRUNK
no nameif
no security-level
no ip address
interface GigabitEthernet0/0.1000
description ASIAKAS-1
vlan 1000
nameif asiakas-1
security-level 100
ip address 172.32.100.2 255.255.255.0
interface GigabitEthernet0/0.2000
description ASIAKAS-2
vlan 2000
nameif asiakas-2
security-level 100
ip address 172.32.200.2 255.255.255.0
route asiakas-1 10.10.10.0 255.255.255.0 172.32.100.1 1
route asiakas-2 10.10.10.0 255.255.255.0 172.32.200.1 2
group-policy ASIAKAS-1-GP attributes
vlan 1000
group-policy ASIAKAS-2-GP attributes
vlan 2000
Basically to my understanding in the above situation the "vlan xxxx" configuration under group-policy defines the eggress interface of the traffic from the VPN and therefore the route for vlan2000/GigabitEthernet0/0.2000 would apply in the case (and provide the next-hop IP) where the VPN user was connecting with a connection using group-policy ASIAKAS-2-GP
I tested this setup and it seemed to work fine. Though this would naturally be an administrative nightmare to manage. (As would be the PBR solution mentioned in the original post)
I'm not sure if I'm making any sense
- Jouni