Dynamic VPN tunnels with a Engenius EVR100 or Netgear

[Anonymous]

I cannot get the vpn to work with a Engenius EVR100. Is there a trouble shooting guide for vpn's? Or a debug mode so I can see why it is not coming up? I have setup VPN's off this router before with different end points but I cannot get it to talk with the Adtran. The remote ends are off dynamic addresses, so I have it setup as dynamic accepting any remote ID. Local ID is the registered domain for the Adtran WAN address (also the domain that is resolved for the remote). I have got the Adran to talk to a pair of static Netgear routers. (I cannot get it to work off a Netgear that uses a dynamic address either) I have all the rest of the settings (encryption, key, local and remote addresses) the same, and I have tried both aggressive and main modes. I have worked in Netgear, Linux, Sonicwall, and others and this has me stumped. Thanks!! - Jeremy

[Anonymous · Accepted solution]

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

[Anonymous]

:

I went ahead and flagged this post as “Assumed Answered.”  If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Levi

[Anonymous]

:

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Levi