Cisco 300-730 SVPN common mistakes
Cisco 300-730 SVPN · Understand the traps and how to avoid them.
Treating IKEv2 as a drop-in replacement for IKEv1 and configuring it with the same policy assumptions, then failing to notice that IKEv2 proposals are matched as a single ordered object (encryption, integrity, PRF, DH group) rather than as independently negotiated transforms.
Most candidates learn IKEv1 first, where crypto maps and transform sets allow mixing and matching proposals. IKEv2 on IOS/ASA uses ikev2 policy/proposal constructs where a proposal bundles all algorithms, so a partially matching configuration fails Phase 1 with NO_PROPOSAL_CHOSEN and the candidate cannot read the symptom.
What to do instead
Memorize the IKEv2 proposal structure as a tuple: encryption, integrity, PRF, DH group. Practice reading 'IKEv2-ERROR: Received notify type NO_PROPOSAL_CHOSEN' as a proposal mismatch, then verify with 'show crypto ikev2 sa' and 'show crypto ikev2 proposal' on both peers, confirming the proposal is attached to the correct policy priority.
Configuring a site-to-site tunnel with matching PSKs and identical crypto but forgetting that the interesting traffic ACL on one side must mirror the other side's exactly (source and destination swapped), then assuming the tunnel is broken when only one direction passes traffic.
The ACL defines what gets encrypted and also acts as a selector check during Phase 2. Asymmetric ACLs cause one peer to reject the proxy-ID or to route only half the flow into the tunnel, producing 'one-way ping works' symptoms that look like routing or NAT faults.
What to do instead
Always write the ACL as a mirrored pair and verify with 'show crypto ipsec sa' that both encrypt and decrypt counters increment. Remember that on ASA the ACL is a tunnel-group/ipsec match while on IOS it is a crypto map match; check proxy-IDs with 'show crypto ipsec sa' and debug crypto condition-based debugging rather than blanket 'debug crypto ipsec'.
Blaming the VPN when the failure is actually NAT or routing: candidates skip verifying that the encrypted packet is being translated, or that return traffic is routed back into the tunnel, and instead rebuild the crypto configuration.
NAT and VPN interact in non-obvious ways. Overlapping subnets, missing NAT exemption (identity NAT) for tunnel traffic, or a default route pointing out the wrong interface all masquerade as VPN failures. Candidates under time pressure jump to crypto because it is the topic being tested.
What to do instead
Establish a layered troubleshooting order: interface/route, then NAT exemption, then IKE, then IPsec, then application. On ASA verify with 'show nat' and 'packet-tracer'; on IOS verify with 'show ip nat translations' and confirm the crypto map is applied to the correct egress interface with 'show crypto map'.
Configuring DMVPN Phase 3 or FlexVPN and assuming spoke-to-spoke traffic will flow directly without confirming that NHRP registration succeeded and that the spoke has a route to the other spoke's tunnel address.
DMVPN requires several coordinated pieces: NHRP registration to the hub, a tunnel source that matches the NBMA address, and (in Phase 3) shortcut switching with 'ip nhrp redirect' on the hub and 'ip nhrp shortcut' on the spokes. Candidates configure the tunnel but omit one of these and then cannot explain why traffic still hairpins through the hub.
What to do instead
Verify NHRP with 'show ip nhrp' on hub and spoke, confirm the spoke's NBMA address appears as registered, and check that the hub has 'ip nhrp redirect' and the spokes have 'ip nhrp shortcut'. Confirm the tunnel protection profile is applied to the tunnel interface and that the overlay routing protocol (or static) advertises the tunnel network.
Treating anyconnect/SSL VPN remote access as a single feature and failing to distinguish the components: the interface and port, the trustpoint/certificate, the connection profile, the group policy, and the AAA method - then guessing which one is misconfigured.
Remote access VPN on ASA/FTD is a chain of dependent objects. A failure can be at the TLS handshake, at authentication, at authorization (group policy assignment), or at address assignment. Candidates who cannot name the chain cannot localize the fault and waste time changing unrelated settings.
What to do instead
Learn the dependency chain in order: interface/port enabled, certificate trusted, connection profile bound to interface and group policy, AAA server reachable and method correct, address pool with free addresses. Use 'show vpn-sessiondb detail anyconnect', 'debug webvpn 255' and 'debug aaa authentication' to localize which link breaks.
Assuming a certificate-based AnyConnect deployment will work because the certificate exists, without checking that the full chain is trusted by the client, that the identity certificate is bound to the correct trustpoint, and that the FQDN in the certificate matches the URL users connect to.
Certificate problems fail at the TLS layer before any VPN authentication occurs, and the client error is often generic. Candidates focus on the VPN configuration and never inspect the certificate chain, SANs, or trustpoint binding.
What to do instead
Verify the trustpoint is enrolled and associated with the interface, that the certificate contains the correct FQDN in the SAN, and that the client trusts the issuing CA. Test with 'show crypto ca certificates' and 'show run webvpn' to confirm the trustpoint is referenced in the interface configuration.
Configuring IKEv1 with a wildcard PSK or a mismatched key and being unable to explain why the tunnel fails, because the candidate never learned that the peer identity used for PSK lookup depends on the configured identity type (address, hostname, or user-FQDN).
In IKEv1 the PSK is looked up by the peer's identity, which is derived from the configured identity type and the aggressive/main mode exchange. If the identity type differs between peers, the lookup fails even when the literal key string is identical. Candidates compare keys and conclude they match.
What to do instead
Confirm the identity type on both peers ('crypto isakmp identity' on IOS, tunnel-group general-attributes on ASA), and prefer explicit per-peer keyrings over wildcard keys. Read 'debug crypto isakmp' for the identity being used in the key lookup, and verify with 'show crypto isakmp sa' that Phase 1 reaches QM_IDLE.
Ignoring MTU and fragmentation when troubleshooting a tunnel that establishes successfully but stalls on large transfers or specific applications, then rebuilding the crypto configuration instead of testing packet size.
IPsec and TLS encapsulation add overhead; if DF is set and PMTUD is blocked, large packets are dropped silently while pings and small requests succeed. Candidates see 'VPN is up' and look elsewhere, missing the classic 'works for small packets, fails for large' pattern.
What to do instead
Test with progressively larger pings ('ping size df-bit') to find the failure threshold, then adjust 'ip mtu'/'ip tcp adjust-mss' on the tunnel interface or the crypto map's TCP MSS adjustment. Recognize the symptom pattern as an MTU/fragmentation issue before touching IKE or IPsec policy.
Mixing up which side of a tunnel initiates and which device holds which role in GET VPN, FlexVPN, or DMVPN, then applying configuration to the wrong device or expecting a hub to initiate to a spoke.
Each architecture has a defined control-plane initiator: DMVPN spokes register to the hub, FlexVPN has an IKEv2 initiator/responder relationship, and GET VPN separates key servers from group members. Candidates who memorize commands without the role model apply them backwards.
What to do instead
Before configuring, write down the role of each device and the direction of the control exchange. For DMVPN, spokes initiate NHRP registration; for FlexVPN, confirm which side has the IKEv2 profile with the matching authentication method for the initiator. Verify with 'show crypto ikev2 sa' that the SA initiator matches the intended design.
Skipping the verification and maintenance step after bringing a tunnel up: candidates never check SA lifetimes, rekey behavior, or logging, and are then unable to answer questions about why a tunnel drops after a set interval.
SA lifetime expiry, rekey failures, and DPD timeouts are common operational causes of intermittent drops, but they only appear after time has passed. Candidates who only test the initial bring-up never see these behaviors and cannot diagnose them in scenario questions.
What to do instead
Learn the lifetime and rekey parameters for IKE and IPsec SAs on both platforms, and how DPD detects dead peers. Practice reading 'show crypto ipsec sa' for remaining lifetime and 'show crypto ikev2 sa detailed' for rekey state, and use syslog with the appropriate logging level to capture rekey and DPD events rather than relying on a single successful ping.