Cisco Secure Firewall Threat Defense can terminate both site-to-site and remote-access VPNs, but the two designs fail in different ways.<\/p>\n
A site-to-site VPN connects networks behind two gateways.<\/p>\n
A remote-access VPN connects an individual user device to a VPN headend, normally using Cisco Secure Client.<\/p>\n
The current 350-701 SCOR<\/a> v2.0 blueprint explicitly includes configuration of both site-to-site and remote-access VPN on Cisco Secure Firewall, plus troubleshooting of VPN tunnel establishment.<\/p>\n A site-to-site VPN normally uses IPsec between two security gateways.<\/p>\n Cisco Secure Firewall supports IKEv1 and IKEv2 for site-to-site VPN, with preshared keys or certificates depending on design.<\/p>\n The gateways negotiate the security association and then protect traffic between the defined networks.<\/p>\n The key operational objects are therefore:<\/p>\n If those pieces do not line up on both peers, the tunnel can fail or pass only some traffic.<\/p>\n A broader IPsec tunnel<\/a> explanation helps with the encryption model, but Secure Firewall troubleshooting requires checking the policy and state on the actual FTD headend.<\/p>\n Site-to-site troubleshooting is easier when the tunnel is treated as two related agreements: the peers must first establish IKE security, then they must negotiate the IPsec security associations that protect the interesting traffic. A successful IKE exchange proves peer reachability, identity, and a compatible IKE policy; it does not prove that the protected networks, traffic selectors, or data-plane permissions are correct.<\/p>\n Traffic counters matter because an apparently established tunnel can still be idle or one-sided. If encapsulation increases but decapsulation does not, investigate the remote peer, routing, return path, selectors, and upstream filtering. If neither side’s counters move when a test flow is generated, the problem may be before encryption: routing, NAT, traffic matching, or access policy can prevent the packet from ever entering the VPN process.<\/p>\n Remote-access VPN has additional dependencies because a user device has to join the tunnel dynamically.<\/p>\n Cisco Secure Firewall supports Secure Client remote access over TLS\/DTLS and IPsec IKEv2, depending on configuration.<\/p>\n The workflow includes:<\/p>\n A remote user can therefore \u201cconnect to VPN\u201d while still being unable to reach an application.<\/p>\n Tunnel establishment and traffic forwarding are separate troubleshooting stages.<\/p>\n For either VPN type, verify that the endpoints can actually reach each other.<\/p>\n For site-to-site:<\/p>\n For remote access:<\/p>\n Do not spend time debugging encryption proposals if the peers cannot establish the initial network connection.<\/p>\n Remote access introduces another control plane before protected traffic is possible. The user must reach the headend, negotiate a supported TLS\/DTLS or IKEv2 session, validate the server certificate, match the intended connection profile, satisfy authentication and authorization, and receive the network parameters needed for the session.<\/p>\n Cisco Secure Client telemetry is useful because it shows the endpoint side of that sequence. DART bundles can capture client logs and diagnostic information for cases that are difficult to reproduce interactively. On the headend, connection events and VPN session details reveal whether the failure occurred before authentication, during address assignment, or after the tunnel was established.<\/p>\n IPsec VPN establishment has stages.<\/p>\n IKE negotiates the secure control relationship and authentication.<\/p>\n IPsec then protects the actual data traffic.<\/p>\n A tunnel can therefore fail because:<\/p>\n This is why a single \u201cVPN down\u201d status is not enough evidence.<\/p>\n Identify how far the negotiation progressed.<\/p>\n IKE failures and IPsec failures leave different clues. If the peers never form an IKE security association, focus on peer reachability, identities, certificates or preshared keys, supported proposals, and the configured IKE version. If IKE succeeds but the child or IPsec security association does not, compare the protected networks, encryption and integrity parameters, PFS expectations, and the traffic that should trigger negotiation.<\/p>\n Time and certificate validity can also matter. A certificate-based VPN can fail even when routing and crypto proposals are correct if a certificate is expired, untrusted, missing a required usage, or presented for a name the client is not connecting to. That is why \u201cTCP 443 is open\u201d is only the first reachability check for a remote-access deployment.<\/p>\n A common site-to-site problem is asymmetric configuration between the peers.<\/p>\n Examples include:<\/p>\n A tunnel can even appear established while selected subnets fail because the crypto selectors do not include them.<\/p>\n Always verify the actual networks being encrypted.<\/p>\n NAT is another common boundary in site-to-site designs. The packet that should be protected must match the VPN’s intended inside and outside addressing. If a translation changes the source or destination before the crypto selection logic expects it, the traffic may miss the tunnel or negotiate selectors that do not match the peer. The exact configuration model varies by platform and topology, so verify the packet path rather than assuming a generic \u201cNAT exemption\u201d statement automatically applies.<\/p>\n Overlapping address spaces create a similar problem because routing can be correct syntactically while the peer cannot distinguish the two sides as intended. In that case, the design may require translation or readdressing before IPsec policy can produce an unambiguous protected path.<\/p>\n Remote access depends heavily on user authentication and Secure Client state.<\/p>\n Cisco’s current troubleshooting documentation recommends collecting a DART bundle for client-side problems.<\/p>\n Useful headend and client evidence includes:<\/p>\nSite-to-site VPN connects gateways and networks<\/h2>\n
\n
Remote access adds the user and endpoint<\/h2>\n
\n
Start with reachability before crypto<\/h2>\n
\n
\n
Then separate IKE from IPsec<\/h2>\n
\n
Site-to-site failures often come from mismatched policy<\/h2>\n
\n
Remote-access failures add AAA and client state<\/h2>\n
\n