ASA S2S VPN with route-injection

[danailpetrov]

Hi all,

I have a specific need related to route-injection feature. I am using it in conjunction with iBGP so I can start advertising the routes as soon as the S2S VPN is up & running. However, because of the nature of policy based IPSec the remote prefix will be only injected after the session is established (e.g. once the interested traffic is detected & thus triggers the session establishment as a result if which I should get the prefix injected & advertised to the network). However, in my topology the ASA is NOT in the way of the traffic and this creates the chicken-egg problem - I am unable to advertise the route for the remote S2S destinations to the internal network in order to get this direct that traffic through the ASA before the session is established - and I cannot establish the session before I get the traffic for it. 

Now, I can eventually do static routes for all S2S VPN networks & advertise them through iBGP regardless of whether or not the session is established and it will work. The problem is however that I have two exit points in my network and I don't know whether the remote S2S network will be terminated via site A or site B. (Both DCs - Site A and Site B have S2S VPN Termination points)

What I want to do is if there is any way possible to distinguish between the static routes which I can manually create and these injected through the RRI (Some IOS version do support that reverse-route tag option, but unfortunately it is not supported on the ASA :(). This way I should be able to advertise these networks from both locations (Site A/Site B) with some metric added (MED +100) and when RRI appears - that'll be more preferred and in theory everything should be okay). Unfortunately however on ASA there are no route tags and I couldn't find a way to differentiate those. 

Another option would be using BGP with advertise maps (in conjunction with existing/non-existing ones) but that's pretty ugly meaning I will need to create a BGP config (map) for every single prefix/S2S destination.

So I am looking for some more elegant solution (if there is such?) :| 

Any thoughts will be more than welcome!

[Florin Barhala]

What if you try: Interface-mode site-to-site tunnels

[danailpetrov]

Can you please elaborate? What do you mean by interface-mode? (if that's what I'm thinking about, I am not sure - a) how would that help and b) if it's supported on ASA at all)

[Florin Barhala]

https://supportforums.cisco.com/t5/vpn/route-based-vpn-vti-for-asa-finally-here/td-p/3046928

[danailpetrov]

Thanks Florin - I wasn't aware of it. However, I still cannot see how can that be helpful in my case? Do I miss something? 

[Florin Barhala]

I think if you post a diagram while also learning how VTIs work can get us closer to the solution.

[danailpetrov]

Sure. 

I believe I do understand how the VTIs work, but I am not sure if this setup is doable in my case.

A diagram is added below. Some key points:

• There are three major sides - Site A, Site B and Campus. All these locations are geographically separated.  
• Border Routers generate the default route 0.0.0.0/0 and distribute it across the whole network.
• Campus distribution routers have multipath for 0.0.0.0/0 via Site A and Site B.
• vpdz devices are Cisco ASA used for S2S VPN to 3rd parties & partner networks. They should advertise S2S network(s) to 3rd parties they have established adjacency with. The problem is that:
  • a) RRI either can advertise S2S networks permanently (e.g. as long as VPN is configured - the network will be injected to the routing table & being advertised to the internal network) which means that MultiSite / HighAvailability setup is not doable (think about scenario where SiteA and SiteB establish VPN Session to the same 3rd party. There should be a way to know which one is the "Active" one);
  • b) if RRI is configured to dynamically advertise (e.g. only after successful IPSec adjacency) then traffic will not be routed to the VPDZ devices (because the Internal network will follow it's default route via fwbe devices, which are used as perimeter/Internet firewall);

Hope that makes it clearer...

[Florin Barhala]

Hi mate,

Sorry for the delay but I just had to find the time to go trough all info and make sure I got this. Now I am back with couple questions:
- Is this live or just on paper?
- suppose it's 100% deployed how is one "3rd party" connected to both SiteA and SiteB? Suppose 3rd party has just one equipment how did they configure two identical Enc Domains on the same appliance? Yes there are some vendors that give you some room but I just want to make sure we're not chasing fireflies here.
If we understand 3rd party config a bit more we can then provide redundancy accordingly.

Meanwhile back to your scenario: do you want siteA and siteB to be somehow in sync and know about each other's state or can we simply think the two sites as primary and secondary and "configure siteB" just as a failover point for siteA?

If we want sites in sync I think we should add "a dedicated sync link" in between; did you consider VXLAN for this maybe?

[danailpetrov]

Hi fella,

thanks for your time - really appreciate it. 

To answer your questions:

- Yes, this is 100% working/production environment.

- At the moment we have variety of 3rd parties connected to only one site with no fail-over / site-failure backup. A recent requirement came from the business so we can support multi-site failover where 3rd parties can connect to either SiteA or SiteB but also to be able to distribute the load of the Internet circuits (atm SiteA is handling these all). I don't think we'd ever have a 3rd party that would require simultaneous connections (to both SIteA - SiteB) and I cannot see a point doing it because load-balancing will be impossible due to the nature of the firewall dropping traffic for sessions which do not look right (e.g. SYN-ACKs for session which SYN's has gone through the other link..)

Typical 3rd party config would be same crypto map with multiple neighbours in - e.g. SiteA and SiteB. As long as SiteA is active - it'll be preferred by that particular 3rd party. And we can stagger - for the next third party we give SiteB first and SiteA as backup... and so on.. 

Both sites are completely separated in terms of Layer2/Layer3 (well, we have some stretched VLANs (via OTV), but only for migration purposes and ideally should get rid of them at some point). VXLAN isn't really needed here, IMO. Also, our setup is somewhat "Dual Active DC" deployment (not primary/secondary or active/standby - we run services off of both DCs if that makes sense..)

It's such a shame that something as basic as route tag isn't supported for either static routes or RRI (it is supported on regular IOS/IOS-XR/XE/NX-OS). That would have solved all these issues... Having a way to distinguish between manually created statics and RRI will give me a way to set different BGP attributes (MED/Local-Pref/Community/etc) and thus I can always know which sites simply advertises these prefixes only to attract traffic to them (e.g. when session is not up&running) and which sites have actually got their session to the 3rd party established (and make it more preferable). Another "problem solver" could have been the nature of the traffic - if we were always the "called party" and never had to initiate sessions first. Then it would have been a piece of cake.. 

I have one workaround which would be doing these static routes with route-tags on the routers before the ASAs and advertise the networks from there to attract the traffic to either SiteA or SiteB, but it's not ... "elegant" to say at leats (combination of static routes and BGP for the same prefixes on multiple devices - someone's gonna swear at me ... a lot!)

I really ran out of options though ... so ... I don't know.. :\ (I guess I can put a link to this thread in the LLD so people can see I tried and actually made an effort lol :D)

[Florin Barhala]

Fortunately you covered it all. You really have a nice setup there but you hit inherent ASA limitations. This is what Cisco did for many years: limited routing capabilities on the firewalls. I know/work with a vendor that has it both: FW, VPN and router-level routing but that's of no help today.

Best of luck!

[Frazer_Stockton]

As far as I'm aware, there are two methods for implementing redundant VPNs on an ASA. 

1) If your 3rd parties support a route based VPN - configure VTIs and overly unicast BGP. You can then weight a preferred path, and prepend a less desirable one to ensure synchronous routing over the primary and secondary tunnel. eBGP can be redistributed into your IGP with a higher and lower cost for prefixes learned via the primary and secondary tunnel.

2) Configure the ASAs with dynamic crypto maps, and enable RRI. Dynamic crypto maps operate differently to static crypto maps in conjunction with RRI. The ASA will only inject a prefix into the routing table if there is an active SA, whereas with static crypto maps - it's always there irrespective of whether the VPN is up. This solution is fraught with caveats, one of which you've outlined in that the remote side must initiate the tunnel. It's a total botch-job in my opinion, but many have had to make do with this for years until VTIs come along.

In response to your earlier post:

I have a specific need related to route-injection feature. I am using it in conjunction with iBGP so I can start advertising the routes as soon as the S2S VPN is up & running. However, because of the nature of policy based IPSec the remote prefix will be only injected after the session is established (e.g. once the interested traffic is detected & thus triggers the session establishment as a result if which I should get the prefix injected & advertised to the network). However, in my topology the ASA is NOT in the way of the traffic and this creates the chicken-egg problem - I am unable to advertise the route for the remote S2S destinations to the internal network in order to get this direct that traffic through the ASA before the session is established - and I cannot establish the session before I get the traffic for it. 

• If RRI is enabled against a static crypto map, a static route to the remote peer's subnets will constantly be present in the routing table.
• If RRI is enabled against a dynamic crypto map, a static route to the remote peer's subnets will only be present in the routing table, if there is an active SA. The caveat being - a VPN must be initiated from the remote side. (There are ways around this, IP SLA on the remote side etc)

What I want to do is if there is any way possible to distinguish between the static routes which I can manually create and these injected through the RRI (Some IOS version do support that reverse-route tag option, but unfortunately it is not supported on the ASA :(). This way I should be able to advertise these networks from both locations (Site A/Site B) with some metric added (MED +100) and when RRI appears - that'll be more preferred and in theory everything should be okay). Unfortunately however on ASA there are no route tags and I couldn't find a way to differentiate those. 

• You can specify a tag when redistributing static routes within a dynamic routing protocol on ASA, and you can set a custom metric. However if said routes originate from a static crypto map, you have no way of dynamically removing the preferred route from your downstream routers/core switches when the primary tunnel goes down.

ADL-EDI-FW01# s ver | inc Hardware
Hardware: ASA5506, 4096 MB RAM, CPU Atom C2000 series 1250 MHz, 1 CPU (4 cores)

ADL-EDI-FW01(config) router ospf 100

ADL-EDI-FW01(config-router)# redistribute static subnets metric-type 2 metric 1000 tag 1000

tl;dr - If possible, I would suggest going with the BGP over VTI solution.