cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
719
Views
10
Helpful
9
Replies

Multiple AnyConnect vpns migration scenario

subhadip.das
Level 1
Level 1

Hi,

 

I am working on a migration scenario where we have an existing RA vpn of company ABC through Cisco Anyconnect.

 

Existing setup:

Users connect to "remoteaccess.abc.com" which resolves to the outside interface IP of the ASA 100.1.1.1. The clients set up a tunnel to the outside interface of the ASA and access the office network if and only if they are authenticated successfully. All tunnels are SSL/TLS tunnels, no IPSec is used.

 

The ASA terminates the tunnel and selects the proper tunnel group, in this specific case by using a certificate map.

  1. The tunnel group specifies, amongst others, how to authenticate the client. In this case the ASA.
  2. Checks the client for a valid certificate.
  3. Prompts the user for additional credentials (username/password).
  4. Sends the user credentials to a Radius server that validates the username/password against active directory servers.

Migration scenario:

Company ABC has merged with another organization XYZ. The proposed solution is to use URL "remoteaccess.abcxyz.com" which resolves to the same outside interface IP. We're using LDAP for the new authentication method.

So far I have tried below without success.

 

1. From the ASA a CSR is raised for the new domain and signed by CA.

2. New set of server and client side certificates are installed.

 

Question:

Is this solution correct or do we need to create a different interface/sub-interface on the ASA (with a different IP)?

Do we need to have one server side certificate and different CA certificates for the two different domains?

 

Any help would be much appreciated.

 

P.S. The two organizations have different user policies and IP pools.

9 Replies 9

Cristian Matei
VIP Alumni
VIP Alumni

Hi,

 

  So for each company you'll be having different sets of tunnel-groups/group-policies, it's just  matter of both companies connecting to the ASA on the same outside interface? In this case you just configure tunnel-groups/group-policies, import the CA certificate of the CA that issued certificates for company XYZ into the ASA, and have the company XYZ clients trust the CA that issued certificated for the ABC company(cause the ASA uses the ABC issued certificate). You can't make the ASA use for the same interface, two different certificates.

 

Regards,
Cristian Matei.

Hi Cristian,

 

Thank you for your answer. If I understand it correctly...two scenarios are possible.

 

1. Using a single interface on the ASA:

Configure tunnel-groups/group-policies, import the CA certificate of the XYZ CA into the ASA and have the company XYZ clients trust the ABC CA. So, on ASA there will be one identity certificate (existing ABC) and two CA (XYZ and ABC). Do they all have to be in one trust chain?

 

2. Use two different interfaces:

One for existing ABC vpn and one for new XYZ vpn and both have their own identity and CA cert chains?

 

I am not too clear about certificates. So, a little bit more explanation or link would be very helpful.

I have tried checking some of the existing solutions in the community, but couldn't find similar situation.

 

Kind regards,

Subhadip

 

Hi,

 

    Yes, both options are valid and will work, 100%. As for the answer to " Do they all have to be in one trust chain", no they don't, in order to allow exactly this setup.

 

Regards,

Cristian Matei.

Thanks Cristian. I will try the different solutions and share the results.

What if you get a new certificate with multiple SANs for the outside interface?

SAN1: remoteaccess.abc.com

SAN2: remoteaccess.abcxyz.com

 

You can even define a group-url for remoteaccess.abc.com that maps the connections to the old tunnel-group so that those users won't even notice a difference when connecting.

Hi,

 

@Gustavo Medina The mutual CA trust is still a required step (CA import on ASA and endpoints, as their certificates are being issued by different CA's), even with those 2 SAN's within the certificate. If i understand what you're saying , is that he can end up using a single connection-profile/group-policy by doing certificate-mapping, this is an option as long as he doesn't have different authorisation requirements per company. Within the same optimisation lines, with a backend RADIUS server like ISE, from where you can get per user authorization, you can go ahead and use a single connection-profile for all your incoming RA connections, as authorization being received from a remote-server, you no longer need a 1-to-1 mapping between  connection-profile and a group-policy.

 

Regards,

Cristian Matei.

 

Regards,

Cristian Matei.

Hi @Cristian Matei 

 

Absolutely. The ASAs identity certificate with multiple SANs will only address the server certificate portion and serves as a workaround in this particular use case as we cannot attach multiple certificates to the same interface.

 

For the other portion (client certificate authentication) yes, the headend must have the appropriate trust chain installed and if there are clients that will have both certificates and can connect to the the 2 TGs then we also need to take into consideration how that selection will be... manual or automatic? Manual will mean that the users will be prompted to select the right certificate which Im not sure if is desired as it may be confusing for some users.

 

The other option is automatic, can define cert matching on the profiles for this. This is how the process works:

Anyconnect Client:

  • Enumerates certificates from all available stores unless excluded on the local policy file.
  • Removes from the list of retrieved client certificates any certificate that does not comply with the certificate match criteria specified by the XML profile. If a cert match was not defined then it will use the default criteria. (KU of Digital signature [or no KU], EKU of Client Auth [or no EKU]).
  • Removes from the remaining list any certificates that came from a store not specified in the profile.

 

For the last point (authorization):

What I was suggesting to make the migration smoother is to simply configure a group-url of remoteaccess.abc.com for the original Tunnel-Group, so that existing users will have the same experience when connecting to remoteaccess.abc.com (same authorization as before)

 

For new users that will connect to remoteaccess.abcxyz.com they can be mapped to the new Tunnel-Group in multiple ways, depends how the admin prefers the flow to be meaning, group-alias, group url, cert-mapping.

 

Another option as you point out is to have a single TG for everybody and then assign different GPs or attributes which I also like.

 

Regards,

-Gustavo

 

Hi,

Today I had a discussion with the CA administrator. It was decided that the option to use multiple interfaces on ASA would be used. This is because the ABC and XYZ CA cannot have a trust chain.

 

Kind regards, 

Subhadip

Hello Christian, Gustavo,


I am still struggling with the solution. So far I have tried to simulate the setup in a lab environment with some modifications.


Current situation is:

1. For simplification, I am using local authentication only. I understand that with different authentication requirement e.g. 1st company RADIUS and second company LDAP, we cannot use same trustpoints.

2. Installed the CA certificate of remoteaccess.abcxyz.com in the client as well as in the ASA. But the browser in the client pc gives "security warning" when I try to connect.

Attached current configuration for reference.

 

Kind regards,

Subhadip

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: