Cisco FTD and FMC - RA VPN

[rbdavid94@gmail.com]

Hi Cisco Comm!!

I have a question about RA VPNs: is it possible with Cisco FMC and FTD to use different gateways for each RA VPN Profile?

Say something like this: You have a RAVPN-User configuration with two profiles for connection:

- Profile1 will send all the traffic through the gateway 1.1.1.1 on interface outside1.

- Profile2 will send all the traffic through the gateway 2.2.2.2 on interface outside2.

I would appreciate any ideas or thoughts on this thanks!

[MHM Cisco World]

Even if we can config it' 

It not work since we can not control return traffic.

MHM

[Rob Ingram]

rbdavid94@gmail.com I assume you mean 1 FTD appliance with 2 outside interfaces?

I don't see how that will work (practically speaking), you can only have a default route via one of the outside interfaces (ECMP is not supported for RAVPN) so the return traffic would not come back via the same interface if you connected to a different interface. You could have a static route for a more specific network via another interface (that is not the default route), but that is not practical for a RAVPN where users could connect from random public networks.

[rbdavid94@gmail.com]

Thanks Rob! i was trying to understand that.

I have 1 FTD appliance, and i want to see if it possible to run something like this. But i get what you said.

In these cases, the best practice is to have a different FTD appliance where you configure a different RAVPN with the other outside interface with the default route. Thank you! 

[MHM Cisco World]

Hmm'

Can you try two profile one for each ISP outside'

The ftd routing lookup order is 

Check conn (it check first and since anyconnect initiate traffic it have conn in ftd and ftd use it for retrun back traffic)

Check RIB ( this defualt route here issue)

So can you check.

MHM

[rbdavid94@gmail.com]

I configured that Profile1 with an static route to use ISP1, and Profile2 with an static route to use ISP2.

But the profile2 does not send the traffic to the internet. However the Profile1 works.

[Rob Ingram]

---

rbdavid94@gmail.com wrote:

I configured that Profile1 with an static route to use ISP1, and Profile2 with an static route to use ISP2.

---

I don't know what you are referring to here, please provide a screenshot.

[MHM Cisco World]

You select out1 and out2 in profiles?

Also you can config one default route toward ISP1 and other toward ISP2 with higher AD.

MHM

[tvotna · Accepted solution]

@Rob Ingram, @MHM Cisco World , rbdavid94@gmail.com , adding another default route with higher admin distance via outside2 interface may or may not help. This route is indeed required for such protocols as telnet or ssh, but I'm not sure if it will help in case of SSL VPN. For example, IKE doesn't work in this scenario (at least didn't work in the past).

This is because from-the-box routing from control plane processes was implemented differently on ASA (and inherited by FTD), then routing of through-the-box packets. Even worse, behavior depends on application running on the ASA, such as telnet server, ssh server, IKE server, WebVPN server, ICMP responder, etc. Also, when TCP SYN comes in (e.g. telnet connection to the ASA IP), connection is created, and theoretically ASA/FTD should be able to use egress interface from the connection to route packets back to the client, but in fact it still does route lookup sometimes and drops returning packets with "%ASA-6-110003: Routing failed to locate next hop for TCP from outside2:172.16.2.100/23 to outside2:172.16.11.2/2514", if the interface from the connection entry doesn't match the route in the ASA routing table. This is where 2nd route via outside2 interface helps: "route outside2 0.0.0.0 0.0.0.0 172.16.2.1 100" (note admin distance 100).

Below is a historical note from dev team on this behavior (before ECMP support was added to ASA code):

In case of SSH/TELNET i.e. bi-directional connections, for the initial packet ASA creates a Connection with Forward flow (i.e. Host to ASA) and also Reverse Flow. And these TCP sessions use the mid-path stack of ASA, where return traffic doesn't need to go through route look-up mechanism, and it just uses the Egress Interface of the reverse flow to send packet out.

In case of IKE/UDP or ICMP packets (though inspect icmp is enabled by default for to-the-box connection) IP Stack on ASA Control-Path (i.e. which handles the ICMP traffic) will do a route look-up for the ICMP reply. That look-up return out1 interface as it is the best route, but as it is different from the out2 Interface request was came in, ASA drops the packet with the Syslog you noticed.

When ECMP (traffic zones) support was added, code was re-worked, but issues with from-the-box traffic remained. I think that responses should be route back to outside1 (preferred) interface even if initial to-the-box connection came in to outside2 interface, if ECMP is enabled. This needs to be tested though.

There is a partial VPN support for ECMP. It is supported for SVTIs (Direct Internet Access feature), but I believe that WebVPN is still unsupported. This needs to be tested too.

[tvotna]

BTW, I've tested this quickly in the lab and AnyConnect is able to connect to outside2 interface even if preferred default route is via outside1 interface. The only requirement is to configure secondary default route with worse admin distance via outside2. Traffic comes in over DTLS and replies are routed back through outside2. ASA version is 9.16.4.42.

[MHM Cisco World]

Thanks so much to confirm that.

MHM

[MHM Cisco World]

Sorry for asking but did you try config two profile one for each interface and get cert. For interface and do separate pool.

All above you do and the anyconnect is failed?

Did you get any log message of failure?

Thanks 

MHM