Troubleshooting IPsec Client VPN

State the problem
Identify possibilities
Use the tools to isolate
Correct without causing harm

Things we know
user: ipse-user
conn-profile and group: ipsec-RA
password : cisco

we have full access to ASA and client machine

Problem : Not able to connect and authentication fails

1 step . Make sure we have basic connectivity
launch VPN s/w client
ping from PC to ASA outside interface
not prompting for user name and password. ike phase 1 is not happening
check details in log window present in VPN client
Go to log and click on enable
From log, we come to know that certificate is used for authentication but not much details on issue.

Let’s launch ASDM
Monitoring -> logging -> view _ real time log viewer
Try connecting
Error seen : connection failed with peer; not trust defined
in client lets use pre-shared keys and remove certificate
clear log and try connecting
now it prompting for user and password but still tunnel is not up
Issue : AAA authentication server is not accessible
Check ASA reachability to AAA
Not able to ping
wrong AAA ip was configured . Edit the server
Now authentication is successful
Try connecting client once again . it worked

Check the statistics on vpn client
We have some bypassed (traffic that is not sent through tunnel) packet count which means split tunneling is used.

From client now try to open browser for internal resource. It's not working
ip address 20.0.0.23 is assigned to client
this is issue.

1st check user-profile which is pulled from ACS server
In ACS check for ipsec-user
static ip address 20.0.0.123 was configured for this user on ACS. Let's change it to 10.0.0.123 since our internal network is 10.0.0.0

log back in
authenticate
open browser
we get 10.0.0.123 assigned to client still not able to open web browser
check the logs in ASDM
Inbound TCP connection is denied at ASA
Check the box in IPsecIKEv1 connection profile: Enable inbound VPN sessions to bypass interface access list.
Same checkbox is present under Anyconnet connection profiles. we can check it at one place and it will have affect everywhere
equivalent cli : sysopt connection permit-von
Still not able to open browser
check logs
Issue: routing failed to locate to next hop for TCP outside 10.0.0.123/1667 to dmz2 10.0.0.5/80
here it shows internal server on DMZ interface but actually it is on inside interface
Check routes
Monitoring -> routing -> Routes
everything seems fine here
Issue is in Group policies where we have restrict access to vlan
The sub-interface assigned to VLAN 2 is named dmz2(in this example). The users assigned to this group will only have access out of the interface associated with the VLAN/sub-interface.
we need to uncheck that box
try connecting once again
Now we are able to access internal resource
check for external resource as well google.com
Able to login

Now let's try to use dig cert.
Open vpn client and edit. check the radio button for certificate authentication and use identity cert
save

clear logs on ASDM
go to client and try to connect
not at all connecting
As per logs : connection failed with peer, no turtspoint defined for tunnel-group sales-con-profile
First of all we are not using sales-con-profile . Lets change conn-profile
Config -> Remote access VPN-> Network client access -> advanced -> IPsec -> certificate to connection profile maps -> policy
This looks to be fine
Check Rules . Issue here is sales conn-profile has higher priority over IPSEC-RA
As per our rule, in certificate if there is OU= training map this to sales-con-profile
to fix this :
let’s delete rule 1
now we have only one rule

try connecting once again
still not letting in
Issue : connection failed with peer : 192.168.1.12 no trust point defined for tunnel-group IPSec-RA
we don’t have any digital certificate on ASA connected to that conn-profile

Config -> Remote access VPN-> Network client access -> connection profiles
double click IPSEC-RA
IKE peer authentication :
use identity cert

try once again
Ike phase 1 done
asking for ikephase 1.5 i.e. prompting for user password
internal and external resource both are working this time.

To sum up :
AAA had wrong ip address for AAA server
User had incorrect IP assigned from AAA
certificate to connection profile mapping was wrong
connection profile not linked to ASA certificate
Group was locked down to specific interface/VLAN
VPN users weren’t allow to skip the outside ACL