Switching from pre-shared keys to certificates for remote access VPN
We have old VPN3000 concentrators that service PPTP, L2TP/IPSec and Cisco VPN Client connections from our users. For the L2TP/IPSec and Cisco VPN Client users, we use preshared keys for initial authentication, then have users provide a username and password for the next authentication phase. We are looking at migrating to the ASA platform, which of course does not support PPTP, but we want to maintain L2TP/IPSec and Cisco VPN Client options as well as add AnyConnect capability.
What we would like to do is replace the preshared key authentication that we used with the VPN3000s with machine certificate authentication. We do not want to have to generate user certificates, rather it was our understanding that the ASA certificate would be used to authenticate the ASA to the connecting client, the client would have to import the certificate and set up the VPN clients to trust it, and then still have the users present a username and password for the next authentication phase.
Re: Switching from pre-shared keys to certificates for remote ac
When using machine certificate authentication with l2tp/ipsec this certificate will be used for IKE authentication and afterwards this has been completed the user will have to give the user credentials.
The way this works is you need to have 2 certificates on the ASA, a Root Certificate Authority and an ID certificate, this would mean you need to enroll your ASA to your CA server, then you need to have a machine certificate for each computer that will be connecting since this is the one used for IKE validation.
In the scenario where Cisco VPN client is used, then the machine certificate will not work (AFIK) and instead an ID certificate will have to be granted, and the process is the same as the previous client.
When using Anyconnect is when you might be kind of accurate in your statements, only if you are not using client authentication via certificates, with anyconnect you will use an SSL certificate that the client will need to trust (if not issued by a trusted authority) and the the connection will take place.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...