Jeremy:
Thank you for asking this question in the Support Community. Since the remote devices have dynamic IP addresses, you will need to setup the VPN using Aggressive Mode. The Configuring a VPN Using Aggressive Mode in AOS document will guide you through the configuration and troubleshooting steps (which includes evaluating the debug messages).
Troubleshooting a VPN should be performed in this order.
1) Attempt to bring up the VPN
2) Evaluate the IKE and IPSEC Security Associations
3) Evaluate Debug Output
Attempt to bring up the VPN:
The VPN will be automatically initiated when traffic that needs to be transported across the VPN occurs. You can perform this task manually with a ping command from the Command Line interface of your AOS device. Note that because the IP Address of the dynamically addressed peer is unknown, the VPN can only be initiated from the dynamically addressed peer. There is no method to initiate the VPN connection from the statically addressed peer.
This example uses 10.10.10.1 as the local AOS device’s LAN (private) interface and 192.168.1.1 as the remote VPN device’s LAN (private) interface. You should evaluate your own VPN to determine the device’s respective LAN (private) IP addresses.
Type ping 192.168.1.1 source 10.10.10.1 to generate traffic that should initiate the VPN.
The VPN will take a few moments to initiate, and then traffic should being to flow normally. After a few seconds you should see exclamation marks across for ping returns indicating success. Try the above ping twice before moving on. If you do receive exclamation marks, your AOS device is properly configured and the VPN is up.
Evaluate IKE and IPSec Security Associations:
IPSec VPNs have two phases of negotiation. Phase 1 is IKE. You can view the status of the Phase 1 negotiations between your VPN devices in AOS. If there is an IKE association, move on to Phase 2.
Type show crypto ike sa to view the IKE (Phase 1) security association. If there is no security association, the IKE, remote and local IDs or pre-shared key on your VPN peers do not match. Double check those settings and retry. It is sometimes normal for the IKE security association to be torn down immediately after IPSec negotiates, and that is acceptable.
Type show crypto ipsec sa to view the IPSec (Phase 2) security associations. If there are no associations between your AOS device and the VPN peer, phase 2 failed. You should evaluate the IPSec, and the local and remote networks settings on both of your VPN devices.
If your AOS device shows an IPSec security association, your VPN is up; note that the IKE security association maybe torn down immediately after the IPSec security association is established and that is acceptable.
Evaluate Debug Output:
VPN debug output is broken up into sections that detail each message of negotiation between the peers. The beginning of each section starts with a message that reads “received first message” or “sent first message”; or “second” message, etc. A description of the message is shown, and then the AOS devices response to that message.
Type debug crypto ike to view the IKE negotiation messages. Note that you may need to reissue the ping command to start IKE negotiation again. The debugs that follow are from the initiating or sending device (device you issued ping from); you may be evaluating the same output from the receiving device.
If after issuing the above debug command and the above ping, you do not see any debug output, your configuration is not correct. Double check that the crypto map is applied to the public interface, that the VPN selector access-list is correct, that the correct access-list name is referenced in the crypto map VPN section, that you have a default route, or a route pointed to the remote private network out the public interface and that the ip crypto command is enabled.
I hope that makes sense, but please do not hesitate to reply to this post with any additional information or questions. I will be happy to help in any way I can.
Levi
