Community Ask Me Anything- Configuration, Troubleshooting and Best Practices: AnyConnect Remote Access VPN on ASA and FTD.

[ciscomoderator]

Español

Português

Français

Русский

日本語

简体中文

This event continues the conversation of our recent Community Ask Me Anything event "Secure Remote Workers".

Here’s your chance to discuss more about the configuration, troubleshooting and best practices for AnyConnect secure mobility client on a Cisco Adaptive Security Appliances (ASA) and Firepower Threat Defense (FTD) and its integration with other Cisco security portfolio devices and technologies like ISE and Duo.

This session provides an opportunity to learn and ask questions about various aspects of AnyConnect implementation (using SSL and Ikev2) including (but not limited to) emergency licenses, configuration, deployment and troubleshooting AnyConnect that provides the security necessary to help ensure that your organization is safe and protected in such critical situation.

To participate in this event, please use the button below to ask your questions

Ask questions from Monday 6 to Friday, April 17, 2020

Featured experts

Dinesh Moudgil is a High Touch Technical Support (HTTS) Engineer with the Security team at Cisco. He has been working on Cisco technologies for more than 6 years focusing on Cisco Next Generation Firewalls, Intrusion Prevention Systems, Identity Management and Access Control (AAA) and VPNs. He holds a CCNP, CCDP and CCIE #58881 certifications, and multiple vendors certifications such as ACE, PCNSE and VCP.

Pulkit Saxena works as High Touch Technical Support (HTTS) Engineer in Security Domain with Cisco bring nearly 7 years of experience in the industry to the team. He has hands on experience with multiple firewalls, different VPN solutions, AAA and Next Generation IPS along with delivering multiple trainings. Pulkit holds certifications from multiple vendors, namely Cisco and Juniper, (CCIE Security and JNCIA).

Jason Grudier is the Technical leader on the VPN TAC team in Raleigh, NC. He has been working for Cisco on the VPN team for six years. Prior to joining the team, he was a network engineer at Labcorp. He works primarily with AnyConnect troubleshooting and configuration across all Cisco platforms as well as DMVPN, GETVPN, Radius, LDAP and Certificate authentications.

Gustavo Medina is a Systems Sales Engineer with the Enterprise Networking Sales team. He has more than 10 years of experience in security and enterprise networking. In his career he has focused on different tasks from technical escalations and partner adoption to the revision of Cisco Certification evaluations. Gustavo holds a CCNA, CCNP CCSI, and a CCIE in security (#51487).

Due to the anticipated volume for this high in-demand event, Dinesh, Pulkit, Jason and Gustavo might not be able to answer each question. Thus, remember that you can continue the conversation directly in the Security community.

By posting a question on this event you're giving permission to be translated in all languages we have in the community.

Find further events on https://community.cisco.com/t5/custom/page/page-id/Events?categoryId=technology-support

**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions

[jgrudier]

It sounds like you might have caching enabled in the preferences.xml file. But to be sure, if you go to ProgramData/cisco/cisco secure mobility client/profile and open the profilename.xml file you have configured, please send the bottom portion that starts with . Please modify the portion as that is not good to have public everywhere 😊. If hostaddress and hostname are the same, them modify them accordingly to still be the same.
secret.cisco.com
secret.cisco.com
Would become
blah.blah.com
blah.blah.com
So we know that it is the same value. If it is different then, just modify each to something random.
There is also a field that allows user input into this box.
true
If this is set to false, users will not be able to modify what is populated by the xml profile.
If caching is enabled, and they user types in the FQDN, instead of selecting the HostName from the xml profile, when they connect the next time, it will show the last connection and the HostName.
In this folder, you will see a preferences.xml folder where you can disable cache
C:\Users\\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client

Finally, do you have more than one profile.xml file in the profiles folder? This will populate multiple entries in the user’s anyconnect login box if you do.

[giovanni.augusto]

Thank you both, 

let me try and give you some more information as you requested:

This is the bottom portion of a sample XML profile :

	<ServerList>
		<HostEntry>
			<HostName>COMPANY NAME - CLIENT (COUNTRY)</HostName>
			<HostAddress>https://vpn.company.com</HostAddress>
			<UserGroup>emea_client</UserGroup>
		</HostEntry>
	</ServerList>

So we have hostname (shown as profile name) different than the hostaddress.

The user experience is as follow:

• When a user is logged already in windows and select the profile name and connects then everything goes as expected

• When using SBL instead, a remote worker would connect first via the SBL screen, selecting the profile but when logged in windows, they see the FQDN and not anymore the profile selected. 

Until now even with this visual glitch but the user is connected where he should.

The problem arise if the user somehow is disconnected and needs to reconnect while logged in windows, in that case the agent will see the regular profile name along with an FQDN that is correctly pointing to our Firewall but does not contain the full URL of the profile so it obviously does not allow any connection in.

In this situation the visual glitch can be a problem as people gets confused if they need to chose the profile name or the FQDN that is incorrectly shown in the profile list :)

I hope this gives you all the information you need about our setup and what is happening.

PS : all these screenshot were cleared out of our internal information but were taken from a live test I just performed myself.

[Gustavo Medina]

Hello Guys,

Looks like this is due to:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp53403

You can track that bug for this issue.

Regards,

-Gustavo

[giovanni.augusto]

Hi Gustavo,

Thank you, seems to be exactly what is happening in our case.

Do you know if there is an anyconnect version without this issue?

So far

version 4.7.04056 is affected

version 4.8.03036 is affected

[Dinesh Moudgil]

Hi Giovanni,

At this moment, the bug is in assigned state and plan is to fix it in later releases.

Thanks,
Dinesh

[patelvc7601]

how do I use packet-tracer with RA VPN vpn-filter.

supposed 10.10.10.10 is vpn address & inside address is 192.168.10.3 what should be the syntax for packet-tracer .

packet-tracer input outside will cause to match outside interface access-list ?

Sincerely

Viral patel

[Gustavo Medina]

Hello @patelvc7601 

After 9.9(1) we added the decrypted option to packet-tracer, it is also possible to simulate a packet that comes across a VPN tunnel. The simulated ‘decrypted’ packet would be matched against an existing VPN tunnel and the associated tunnel policies would be applied.

For your example, the syntax would be:

packet-tracer input outside tcp 10.10.10.10 5050 192.168.10.3 decrypted

The tunnel should be established when you run the above command, otherwise you would receive a warning.

Regards,

Gustavo

[giovanni.augusto]

Hello again,

Sorry in advance for a question that has cross references with Cisco ISE.

In case we need to restrict Remote access users based on the country of origin, I know the following:

• Firepower has Geolocation feed and can create ACP rules based on them but not for traffic terminating at the firewall (as RA VPN is)
• Cisco ISE use as RADIUS backend authentication can use Tunnel-Client-Endpoint attribute in authentication/authorization rules, that would provide the public IP used by a connecting client
• Cisco ISE does not have to my knowledge any Geolocation data feed

Based on these considerations I was thinking to look later on to export Firepower Geolocation IP list and build condition objects into Cisco ISE (via REST API) and then match if Tunnel-Client-Endpoint falls into the specific country object allowed for the access.

Now this opens for the following questions

1. Can Geolocation IP data be exported via REST API from FMC?
2. Is possible to somehow create a condition in ISE for an IP to be in one of the subnets listed in an object? (I believe no way)
3. Is there on ISE or on Firepower such features in the roadmap?

Thank you!

[Dinesh Moudgil]

Hi Giovanni,

1. You can get the mapping information from the files "ipv4_country_code_map" and "ipv6_country_code_map" which is located in the following directory " /var/sf/geodb" on the FMC

root@fmcv66:/var/sf/geodb# cat ipv4_country_code_map
and
root@fmcv66:/var/sf/geodb# cat ipv6_country_code_map

This results in an output with IPs and the associated country codes. More about country codes at https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes

If you wish to know the country code from FMC, you can run this perl command on the FMC as root:

root@fmcv66:/var/sf/geodb# perl -MFlyLoader -e 'my $t="country_code_continent_code_map";my @c=("country_name","country_code");my $n=0;my $s="*"x20;foreach my $row (@{SF::SFDBI::connect()->selectall_arrayref("SELECT ".join(",", @c)." from $t WHERE country_code=242")}){print "$s ".++$n.". $s\n";my $i=0; foreach (@{$row}){printf "%9s: %s\n",@c[$i++],$_}}'
******************** 1. ********************
country_name: fiji
country_code: 242
root@fmcv66:/var/sf/geodb#

We also have the following API to retrieve the geolocation objects:

GET geolocation

Request Type: GET

Description: Retrieves the geolocation object associated with the specified ID. If no ID is specified, retrieves list of all geolocation objects.

URL: /api/fmc_config/v1/domain/{domain_UUID}/object/geolocations

URL for GET by ID: /api/fmc_config/v1/domain/{domain_UUID}/object/geolocations/{object_UUID}

For 2. and 3. By no means I am an expert on ISE but it usually does a check based on a condition like an attribute or an identity group rather a list. Do not think this is supported at the moment but if there is any change in information, I will update the thread.

Regards,
Dinesh Moudgil

[giovanni.augusto]

Thank you Dinesh,

Appreciate the support, I will keep an eye on the thread for your update.

This may solve a big problem, at the moment I have seen 3rd party authentication providers return fail condition based on geolocation but at the current status not every Remote Access solution can be authenticated against such providers so it would be good to have it out of the box for either Firepower or ISE

[Marvin Rhoads]

@giovanni.augusto note that if you use Duo MFA (which is supported by FTD-based remote access VPN) and have the Access or Beyond plan you can enforce Duo policies based on user geolocation. For instance, you could prohibit all access from outside your country. You could also make it more granular - for instance, make such a prohibition generally while exempting particular users who are traveling or based abroad.

[giovanni.augusto]

Thank you Marvin,

Would that work in case of using DUO proxy with ISE or it works with DUO with SAML authentication directly from the FTD?

[Gustavo Medina]

Hello Guys,

ISE does not natively provide such service but you can integrate with an MDM (Meraki Systems Manager would work) to provide this service. From the FTD itself, you could configure a control-plane ACL to block unwanted blocks. You can get this information from FMC as @Dinesh Moudgil pointed out, from the geo package itself on cisco.com, from a 3rd party source or using ANSIBLE which I would prefer: 

https://developer.cisco.com/site/ftd-ansible/#!country/country

Definitely the option @Marvin Rhoads refers to, using DUO would me my prefered method. You could do it with the DUO Proxy as documented here:

https://duo.com/docs/ciscoise-radius

https://duo.com/docs/cisco#cisco-ise-using-radius

But this is also possible with SAML, not well documented but this video explains it all:

https://youtu.be/W6bE2GTU0Is

HTH

-Gustavo

https://youtu.be/W6bE2GTU0Is

[giovanni.augusto]

@Dinesh Moudgil @Gustavo Medina @Marvin Rhoads 

Thank you for your suggestions,

@Marvin Rhoads : I will explore the DUO option as soon as I get some free time (!) and eventually make it work in parallel with another MFA supplier we use, do you know if geolocation works with the free license for testing?

@Gustavo Medina @Dinesh Moudgil : I like all option proposed, the most immediate for me now looks like using a control-plane ACL in FTD with geolocation and I have questions about this option:

1. control-plane ACL can be used via flexconfig as far as I know and there were some problems in the past, I guess these are resolved and Cisco support such configuration?
2. In case of control-plance ACL in FTD, can I use directly the geolocation object from SI or do I have to create and update a "LINA" object to use with Flexconfig?
3. going on with this scenario, can I apply this ACL just to one tunnel group? as far as I know this will apply to all inbound remote access for that Firewall, so it means that we would restrict anyone connecting to it?
4. if #3 is a yes (restiction to all connecting users to a FW), would the new VRF-lite feature of FTD 6.6 come in handy and create multiple interfaces and attache the control-plane acl to that specific "restricted outside"? 

While writing these questions I came to think that control-plane ACL  looks less scalable than geolocation at authentication level but I'd like your opinion on that.

[Gustavo Medina]

Hi @giovanni.augusto 

1. Make sure you run a version with this fix https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn78593
2. Would need to use a LINA object.
3. It's a general rule. Not specific per tunnel-group.
4. It should work, I already tested applying policies to specific VRFs and it works but this particular control-plane scenario I haven't. If it does not work then we would need to file a bug. Multi-instance should also work.

I do prefer using DUO for this geo based rules as it will be easier to manage but that's definitely not the only option. Another option would be to separate functions and have a dedicated ASA for your RA VPN connections behind the FTD where you could apply geo based rules for this through-the-box traffic.

Regards,

-Gustavo