Numerous experiences with clients and students implementing Virtual Private Networks (VPNs) with IPSec have shown me that some common misconceptions exist as to their operation and troubleshooting. We will examine three of these using the scenario below between an ASA running version 8.0 code and a Cisco Router running IOS version 12.2 or higher code.
Misconception #1: A Site-to-Site VPN created with the ASDM Wizard is Bidirectional
The commands below are a portion of what would be displayed if the “Preview Commands…” option were selected in the ASDM preferences after finishing the Site-to-Site wizard.
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group2
crypto map outside_map 1 set peer 192.168.11.2
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
Note the set pfs group2 statement above; this default deployment option with the wizard will result in the IKE Phase II proposal of Perfect Forward Secrecy using Diffie-Hellman Group #2. While the IOS Router will support this and agree to it (even though it wasn’t explicitly configured), the tunnel CANNOT be successfully initiated by the site owning that router! For this to happen, the router MUST be configured with the same statement for its Phase II policy in its crypto map.
Misconception #2: The IKE keepalive keeps the Site-to-Site tunnel up
Actually, the IKE keepalive merely insures that the remote peer is reachable. A little-known fact is that the Idle Timeout usually found in the Network (Client) Access for the IPSec client also impacts Site-to-Site tunnels being kept up. A screenshot is provided below showing where this is configured for the default group policy, DfltGrpPolicy.
Studies have shown that if this time interval is increased to be greater than 80% of the Phase II IPSec Security Association lifetime, the tunnel will stay up.
Misconception #3: Allowing IPSec ACL bypass is insecure – Default Wizard option
This appears as a checkbox in the wizard, or could be configured using the CLI command sysopt connection permit-vpn. Two very effective techniques can be used here, the mechanics of which will be discussed in future postings. The first of these would be to configure a VPN Group Filter (done under the Group Policy settings), a feature which applies for both Site-to-Site or Remote Access VPNs. A second effective technique, applicable for both IPSec and SSL VPN Client access, would be to use downloadable access-control lists with RADIUS.
Author: Doug McKillip
Most Common L2L and Remote Access IPSec VPN Troubleshooting Solutions Document ID #81824