07-08-2025 08:12 AM
I'm trying to initialize IPSec tunnel to AWS basing on AWS instructions and it looks that ASA is not even trying to initialize connection.
When I turned on debugging, it looks that ASA is in receiver mode (I see connection attempts from old site), but there are no outgoing attempts. I used "debug crypto ipsec" and "debug crypto ikev1" both without value specified (so 1 I believe) and with 255.
At first attempt I tried to use VPN Wizard with AWS IPs provided, so I suspect that it could be a reason of problems - I have now bunch of different policies and transform sets, maybe that's what's somehow interfering? I'm attaching sanitized config.
07-08-2025 08:16 AM
I dont see you set access-list for VPN map in ASA ?
MHM
07-08-2025 12:39 PM
The ASA not initiating the IPSec tunnel to AWS usually means it’s waiting for traffic to trigger the VPN. Make sure there is actual traffic matching your crypto ACL going from your internal network to AWS — without it, the ASA won’t start the connection.
Check your crypto ACL carefully to confirm it matches exactly the AWS subnets and your local subnets. If it doesn’t match traffic, no tunnel initiation happens.
If you ran the VPN wizard multiple times, you might have leftover or conflicting crypto maps and transform sets. Clean those up to keep only the needed ones. Also, confirm the crypto map is applied on the correct interface.
Don’t forget to exclude VPN traffic from NAT with a NAT exemption rule; otherwise, the tunnel won’t form correctly.
Verify your tunnel-group settings, including the peer IP and pre-shared key, match AWS requirements exactly. Also check that your IKEv1 policies are compatible and in the right order.
To test, generate traffic (like a ping) from behind the ASA to the AWS subnet. Then check the VPN status with show crypto isakmp sa and show crypto ipsec sa.
If nothing initiates, clear existing SAs with clear crypto isakmp sa and clear crypto ipsec sa and try again.
07-09-2025 07:45 AM
@MHM Cisco World @wajidhassan - you were right. There is an access list but I renamed only one of the occurrences so it weren't connected anywhere. After re-doing it (including removal of all the unnecessary ikev1 settings like all this maps) I got phase 1 connection.
However, I'm still unable to connect Phase 2. From what I see, after ASA sends ACK packet for keep-alive, it's not understood by AWS so I get "Packet Malformed" answer and eventually connection is teared down. ASA log in attachment (search for "====" to jump to start of specific events), in ASA i see entries like:
{"event_timestamp":1752054747,"details":"AWS tunnel was unable to decrypt the security payload(s)","dpd_enabled":true,"nat_t_detected":true,"ike_phase1_state":"established","ike_phase2_state":"down"}
{"event_timestamp":1752054753,"details":"AWS tunnel received DELETE for Phase 2 SA with SPI: 0xyz820","dpd_enabled":true,"nat_t_detected":false,"ike_phase1_state":"down","ike_phase2_state":"down"}
I verified config again, including downloading it for the second time and comparing in case of some changes (especially in psk key). Everything looks in order. Time is set up correctly on both sides (though they're in different time zones).
Anything strange that I found is that AWS side has no static route pointing to internal network on ASA side, though is provided as "Remote IPv4 network CIDR" in tunnel settings.
Any ideas how to untangle this?
07-09-2025 07:51 AM
Why local subnet is 0.0.0.0 ?
How you config this ACL
MHM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide