[IKEv1]: Group = salesgroup, Username = salesuser,(18)
IP = 22.214.171.124, Adding static route for client address:
[IKEv1]: Group = salesgroup, Username = salesuser,(19)
IP = 126.96.36.199, PHASE 2 COMPLETED (msgid=d9fcc34b)
[IKEv1 DEBUG]: Group = salesgroup, Username = salesuser,(20)
IP = 188.8.131.52, Received keep-alive of type DPD R-U-THERE
(seq number 0xa780a31f)
[IKEv1 DEBUG]: Group = salesgroup, Username = salesuser,
IP = 184.108.40.206, Sending keep-alive of type DPD R-U-THERE-ACK
(seq number 0xa780a31f)
Here's an explanation of the debug output:
The Remote (220.127.116.11) initiates a session to the appliance (acting as a Server).
The Remote sends its identity type to the Server, along with the group it wants to connect to ("salesgroup").
A matching Phase 1 policy is found: policy 5 of the Remote matches the first policy of the Server).
The Remote initiates IKE Mode Config and the appliance is determining which parameters it has configured for the associated group.
The group authentication is successful, as is the XAUTH authentication via the user account "salesuser"; notice that this message appears here rather than before IKE Mode Config, because the appliance needs to verify whether or not the user is allowed access to the group.
The Remote sends an IKE Mode Config request for the policies defined for the salesgroup group.
During IKE Mode Config, the appliance learns the client type and version.
The Server sends back the IKE Mode Config parameters.
This completes ISAKMP/IKE Phase 1.
Quick mode begins with an exchange of policies.
The internal address of the client is 192.168.2.200 and the proxy message it sends indicates that all of its traffic is to be protected (the group policy is split tunneling disabled).
A check is performed to make sure that the client isn't reconnecting (the Initial Contact feature for Easy VPN); in this example, the client is initiating a new connection.
The appliance compares the proxy information with its first crypto map entry (which is a static one) and finds that it doesn't match this entry (the proxy information doesn't match).
The appliance compares the proxy information with its second crypto map entry, which is a dynamic crypto map for remote access users.
A matching data transform is found.
There is a difference in the data SA lifetime values between the two devices: the lower one (28,800 seconds) is negotiated.
The two IPsec data SAs (inbound and outbound) are created and SPIs are assigned.
Because RRI is enabled, a static route for the Remote's internal address (192.168.2.200) is added to the Server's local routing table.
Phase 2 has completed.
Because DPD was negotiated in Phase 1, DPD now takes place; in this instance, the Remote is initiating DPD (however, both sides of the tunnel will do this periodically based on their local keepalive counters).
Dear Team, I guess everyone is keeping safe. I'm upgraded my Video Surveillance Operations Manager from 7.11.0 to 7.11.2 and i got the below warning message. Please kindly review the attached and advice.
Hello everyone! I have some problem with one host who uses anyconnect. For example when host connect to Cisco ASA, host gets ip address from pool but the public IP of host is not available from my network until host disconnect.For example: Usern...
Hello,I am doing the system settings on a FTD 2130.When I did a copy/paste the token to registrate the license, I got this message "cannot connect to smart licensing server".I followed the quick start guide to do my settings :e.g. outside (dhcp mode), ins...
We thought this was going to be a relatively easy fix to get Secure LDAP up again after ASA upgrade. Recently upgraded an ASA5525 to 9.14.2 and AnyConnect authentication was impacted by cert requirement according the 9.13 release notes we need ...