04-03-2020 05:28 PM - last edited on 04-27-2020 09:00 AM by Hilda Arteaga
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
**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions
Solved! Go to Solution.
04-09-2020 05:20 AM
04-09-2020 06:33 AM
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:
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.
04-09-2020 07:52 AM
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
04-09-2020 08:03 AM - edited 04-09-2020 08:23 AM
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
04-09-2020 05:21 PM - edited 04-09-2020 05:22 PM
Hi Giovanni,
At this moment, the bug is in assigned state and plan is to fix it in later releases.
Thanks,
Dinesh
04-10-2020 12:31 PM
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
04-10-2020 01:58 PM
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
04-10-2020 01:36 PM
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:
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
Thank you!
04-11-2020 01:45 AM - edited 04-11-2020 02:37 AM
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
04-11-2020 03:22 AM - edited 04-11-2020 03:34 AM
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
04-11-2020 07:32 AM - edited 04-11-2020 07:35 AM
@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.
04-11-2020 08:32 AM - edited 04-11-2020 09:31 AM
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?
04-11-2020 09:12 AM - edited 04-11-2020 09:35 AM
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:
HTH
-Gustavo
04-11-2020 09:39 AM
@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:
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.
04-11-2020 10:49 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide