The proposal errors were coming from the remote end. But we’re still not getting phase-1 SA’s.Īlso, it looks like the ASA is not even trying to bring up the tunnel. Once the proposal has been changed, these debug errors no longer show up. We can figure out better security algorithms later.
Proposal 1: AES-CBC-256 SHA1 SHA96 DH_GROUP_1024_MODP/Group 2 The debug gave me this: IKEv2-PROTO-1: (16): Received Policies: Don’t go too high too quickly, as there may be too much information to search through. The higher the number, the more detail you get.
This will show us any errors with IKEv2 (you can substitute IKEv1 if you need to). Instead, I can find this with a debug command: In my case, it’s a little harder, as a third-party manages the remote end of the tunnel. This is easy if you control both ends of the ASA VPN tunnel. The proposals include acceptable combinations of cyphers, hashes, and other crypto information. The first step in troubleshooting phase-1 (IKEv2 in my case) is to confirm that there are matching proposals on both sides. So, phase-1 looks like a good place to focus on. These are hosts that should be able to communicate over the tunnel. This just simulates some http traffic from 10.0.0.1 to 172.16.0.1. Packet-tracer input Inside tcp 10.0.0.1 http 172.16.0.1 http We can try to do this with packet tracer: Perhaps the ASA hasn’t seen any interesting traffic yet and hasn’t tried to bring the tunnel up. In my case, there were no phase-1 SA’s, so there was no point looking for phase-2 SA’s. There should be phase-1 SA’s and phase-2 SA’s for the ASA VPN to work. This is always my first step when troubleshooting. The config all appeared to be there, and the third-party said their config was in place too. A local ASA needed to build a site-to-site (aka L2L) IPSec VPN tunnel to a non-ASA third-party. Yesterday, I assisted with troubleshooting ASA VPN issues.
0 kommentar(er)
