Core issue
There might be many reasons that a VPN tunnel fails to come up on a router. However, one of the most common reasons is if a router is also configured for a VPN Client connection.
Without the ability to disable extended authentication (Xauth), a user cannot select which peer on the same crypto map should use Xauth. That is, if a user has router-to-router IPsec on the same crypto map as a VPN Client-to-Cisco-IOS IPsec, both peers are prompted for a username and password. In addition, a remote static peer (a Cisco IOS router) cannot establish an Internet Key Exchange (IKE) security association (SA) with the local Cisco IOS router. (Xauth is not an optional exchange, so if a peer does not respond to an Xauth request, the IKE SA is deleted.) Thus, the same interface cannot be used to terminate IPsec-to-VPN Clients (that need Xauth) as well as other Cisco IOS routers (that cannot respond to Xauth) unless this feature is implemented.
Resolution
In order to resolve this issue, use the no-xauth keyword with the command crypto isakmp key if router-to-router IPsec is on the same crypto map as a VPN Client-to-Cisco-IOS IPsec. This keyword prevents the router from prompting the peer for Xauth information (username and password).
For additional help, refer to the Disabling Xauth for Static IPsec Peers section of Ability to Disable Xauth for Static IPsec Peers.
