ASA Loopback Interfaces

[paulhughes5]

Hi

I'm fairly new to the ASA platform after having spent the last few years on Juniper SRX.

As part of a new project we are looking to integrate some ASA5545s into a new L3VPN platform and as part of this I'd like to have traffic fail-over between sites using routing, the complication comes with how I want to handle IPSEC VPNs.

First question, do ASAs currently support loopback addresses in multi-context mode (if so where do you configure them)?

Second question, can these interfaces then be used to terminate a site to site IPSEC tunnel?

Any help welcome

Thanks

Paul

[Karsten Iwen · Accepted solution]

The ASA doesn't support the concept of loopback-interfaces. IPsec-VPNs are always terminated on the IP of the interface that protects the traffic.

[paulhughes5]

Is there an alternative solution to allow the creation of logical interfaces I can advertise via routing protocols?

[Karsten Iwen]

No, if you need that flexibility four routing-integration, an IOS-router would be the best choice. The ASA is quite limited here.

[Oliver Kaiser]

Do you want to implement a firewall service for l3vpn customers? In case you want to build a scalable multi-tenancy solution you might wanna look into ASAv and dedicate a virtual machine for each customer and offer redundancy using a 2nd asa for failover.

Let me know which problems you are trying to solve with your design - maybe there is a viable alternative to l3 failover mechanisms and ipsec failover (which could be achieved using backup peers btw).

regards

Oliver

[paulhughes5]

Hi

I'm working with hardware that's already been purchased so a little stuck when it comes to swapping it out.

The idea is that a 3rd party customer will have a VPN to a single IP and that IP can move within our core to another firewall should the primary fail.  I cant use the external facing IP of the firewall as that will be a connected route to the up-steam router.

Trying to get customers to configure anything beyond a single IPSEC tunnel is hard enough without asking them to create backup peers or second paths so we are trying to solve it on our side.

Thanks

Paul

[Karsten Iwen]

The idea is that a 3rd party customer will have a VPN to a single IP and that IP can move within our core to another firewall should the primary fail.  I cant use the external facing IP of the firewall as that will be a connected route to the up-steam router.

So you have the wrong device for the right task ...

For a firewall failure, there is Active/Standby HA. If the active unit fails, the standby unit takes over the VPN. But the VPN still has to be terminated on the IP of the physical interface.

What about splitting the task of firewalling (which will be done by the ASA) and VPN?

[paulhughes5]

Hi

I'm not trying to deal with failure in the same site, this is cross site.

The theory being that a customer connects to DC1 in normal operation to access their services in an L3VPN which can span multiple locations.  If the firewall in DC1 goes down for any reason I want the IPSEC tunnel to come into a firewall in DC2 which connects to the same L3VPN 'cloud'

I have tried to create a 'dummy' interface and direct traffic to that however it seems the ASA won't allow you to route to the physical IP of one interface from another.

[Karsten Iwen]

I understand what you want, but no, that's all not supported on the ASA itself. You could try to automate things through scripting, but that would also be a highly dirty solution because it had to be done on both sides of the tunnel. Be aware that another limitation is that the ASA only does policy-based VPNs, not route-based VPNs.

The ASA is a great device for Remote-Access VPNs, but for highly scalable S2S VPNs, a router is the better choice.

[paulhughes5]

Thanks, missing my SRXs already :D

[WHindriks]

Support for routebased VPNs has been added in ASA 9.7:

The ASA VPN module is enhanced with a new logical interface called Virtual Tunnel Interface (VTI), used to represent a VPN tunnel to a peer. This supports route based VPN with IPsec profiles attached to each end of the tunnel. Using VTI does away with the need to configure static crypto map access lists and map them to interfaces.

Source:
http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/release/notes/asarn97.html#ID-2172-00000128