@Mike.Cifelli  AFAIK, there is no correlation between the threat detection feature and VPN pool assignment. If I recall correctly, the ASA puts the unassigned IP address back to the top of the queue to be assigned next, irrespective of it being shunned or not.    But your situation could be remedied by adding a re-use delay for the VPN pool address assignment. https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/vpn/asa_91_vpn_config/vpn_addresses.html#18588   This way, the ASA does not use the IP address for a certain period after re-assigned back to the pool. You can align this with the shun duration period if you wanted to.      ... View more

Looks like the is sending the IKE_AUTH message with the cert and re-transmitting this till the SA dies.   IKEv2-PLAT-3: (88): SENT PKT [IKE_AUTH] [My_ASA_IP]:500->[REMOTE_PEER_IP]:500 InitSPI=0x73e01ccdd50690cd RespSPI=0xd637074fdd003a45 MID=00000001 IKEv2-PROTO-5: (88): SM Trace-> SA: I_SPI=73E01CCDD50690CD R_SPI=D637074FDD003A45 (I) MsgID = 00000001 CurState: I_BLD_AUTH Event: EV_CHK_EAP_POST_ASYNC IKEv2-PROTO-2: (88): Check for EAP exchange IKEv2-PROTO-5: (88): SM Trace-> SA: I_SPI=73E01CCDD50690CD R_SPI=D637074FDD003A45 (I) MsgID = 00000001 CurState: I_WAIT_AUTH Event: EV_NO_EVENT IKEv2-PROTO-5: (88): SM Trace-> SA: I_SPI=73E01CCDD50690CD R_SPI=D637074FDD003A45 (I) MsgID = 00000001 CurState: I_WAIT_AUTH Event: EV_RE_XMT IKEv2-PROTO-2: (88): Retransmitting packet (88): IKEv2-PROTO-2: (88): Sending Packet [To REMOTE_PEER_IP:500/From My_ASA_IP:500/VRF i0:f0] (88): Initiator SPI : 73E01CCDD50690CD - Responder SPI : D637074FDD003A45 Message id: 1 (88): IKEv2 IKE_AUTH Exchange REQUESTIKEv2-PROTO-3: (88): Next payload: ENCR, version: 2.0 (88): Exchange type: IKE_AUTH, flags: INITIATOR (88): Message id: 1, length: 2445(88): Payload contents: (88): ENCR(88): Next payload: VID, reserved: 0x0, length: 2417 (88): Encrypted data: 2413 bytes (88): IKEv2-PLAT-3: (88): SENT PKT [IKE_AUTH] [My_ASA_IP]:500->[REMOTE_PEER_IP]:500 InitSPI=0x73e01ccdd50690cd RespSPI=0xd637074fdd003a45 MID=00000001 IKEv2-PROTO-5: (88): SM Trace-> SA: I_SPI=73E01CCDD50690CD R_SPI=D637074FDD003A45 (I) MsgID = 00000001 CurState: I_WAIT_AUTH Event: EV_NO_EVENT IKEv2-PROTO-5: (88): SM Trace-> SA: I_SPI=73E01CCDD50690CD R_SPI=D637074FDD003A45 (I) MsgID = 00000001 CurState: I_WAIT_AUTH Event: EV_RE_XMT IKEv2-PROTO-2: (88): Retransmitting packet One possible reason could be an increase in size of certificate causing a fragmentation of the outbound packet. Any chance of getting simultaneous debugs from both sides?  ... View more

I think it is more on an interoperability issue than a security one. When you use clientless webvpn, the ASA has to re-write the content it receives from the backend web pages to present it to the end user. This may not work all the time as there are restrictions to what content the ASA can re-write. Think of this almost as a proxy.   AnyConnect (or client VPN) avoids this by creating a tunnel so that the end user traffic is just routed to the internal network by the ASA. There is no re-write by the ASA, so you access the content as is.   If you ask me, security-wise, clientless can be thought of as more secure than client because it restricts what type of content you can receive while remote to the network. The content received is only web-based and it can be restricted to what networks/resources the administrator publishes on the portal. With client based vpn, you are not restricting what applications the end client can use over the tunnels - only network and ports.   Hope this helps.  ... View more

no matching crypto map entry for remote proxy 172.16.130.0/255.255.254.100/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside Looking at your configs, I can see an extra crypto ACL side on the ISR : ip access-list extended Abuja-IV permit ip 172.16.130.0 0.0.0.255 192.168.0.0 0.0.0.255 permit ip 172.16.130.0 0.0.0.255 172.16.120.0 0.0.7.255 permit ip 172.16.130.0 0.0.1.155 any   Keep the ACL's the same on both sides. What might be happening is that there is some traffic triggering the Phase 2 tunnel from the ISR side. Since it cannot establish completely, it might be tearing down Phase 1 as well.  ... View more

How are you connecting to " ssl_admin" and "ssl_admin_hi". I did not see a group-url or group-alias configured. This may mean that you are hitting the DefaultWebVPNGroup which is the default setting. Do you want the users to pick domain a or b from dropdown? If yes, then configure a group-alias under each of the tunnel-groups and enable "tunnel-group-list" under the webvpn global config.   If you want them to hit the tunnel group directly without a dropdown choice, then configure a group-url for each tunnel-group. For example "https://vpn.domain.com/domaina" or https://vpn.domain.com/domainb"   Another thing that you have not done as per the config is to assign the LDAP attribute map to the aaa-server config.   aaa-server ldapquerysrv1 (inside) hostx.x.x.x ldap-attribute-map sslvpn   ... View more