Identify the endpoints and the traffic that should be protected

A site-to-site VPN commonly connects two networks through security gateways. Users on one site address private destinations at the other, and the gateways protect traffic crossing an untrusted intermediate network. A remote-access VPN typically allows an individual endpoint to connect securely to an organization, often using a VPN client and a gateway or managed service. These designs differ in endpoint identity, routing, authorization and the scope of traffic that enters the protected path.

Start with a diagram that identifies the original packet source and destination, the VPN gateway addresses visible on the outside network and the private prefixes expected inside the tunnel. The gateway may encrypt an original packet for delivery, but the final application still depends on correct routes and access policies at both sites. If a remote workstation is allowed to reach only one subnet, successful connection establishment does not prove it should reach every internal server.

Tunnel definitions and authorization should follow least privilege. It is a mistake to expand the allowed subnets to 0.0.0.0/0 merely to see whether a particular host starts responding. That change can redirect unrelated traffic and expose destinations outside the intended policy. Compare the approved traffic selectors or equivalent policy entries at both ends before widening the tunnel’s scope.

Distinguish IKE negotiation from IPsec data protection

Internet Key Exchange, commonly IKEv2 in contemporary IPsec designs, negotiates security relationships and cryptographic material needed to protect subsequent traffic. IPsec Encapsulating Security Payload (ESP) provides confidentiality and integrity protection according to the selected algorithms and policy. A successful IKE phase does not necessarily imply that every intended application packet has a functioning ESP security association and matching traffic selector.

Authentication can rely on configured credentials or certificates depending on the deployment. Remote-access environments may add user identity controls and multifactor authentication, while gateway-to-gateway deployments often establish identities for devices. Avoid treating a pre-shared key as equivalent to a user authorization rule. A tunnel gateway can trust a peer’s identity but still lack approval to route arbitrary private prefixes through it.

In logs, separate negotiation rejection from absence of matching traffic. An algorithm or identity mismatch may prevent a security association from forming. A route missing toward the protected destination can leave an established association idle. A policy mismatch can cause packets to traverse the ordinary outside route unprotected or be dropped. These symptoms require different corrective action; repeatedly restarting the VPN service does not reveal which part is wrong.

Understand tunnel mode and transport mode without oversimplifying

IPsec tunnel mode encapsulates the original IP packet within a new outer IP packet, a common choice for gateway-to-gateway protection where private packets cross a public or otherwise untrusted transport. Transport mode protects relevant payload portions while retaining the original IP header’s general routing role and is applicable in designs where endpoints and protocol stacks support it. These are different packaging choices, not synonyms for site-to-site and remote-access VPN categories.

Do not infer the active IPsec mode solely from whether the user is at home or in a branch office. Product architectures can use additional encapsulation, control mechanisms or client behaviors. The relevant design question is which addresses remain visible to intermediary routers and which parts of the original packet are protected. The intermediate network forwards based on accessible outer routing information; it normally does not need to learn the organization’s internal private prefixes.

Network Address Translation Traversal (NAT-T) is commonly relevant when an IPsec connection crosses NAT devices. It can encapsulate protected traffic to navigate translation behavior, but support and negotiation still must align between peers. If a tunnel works from one network but fails from a hotel or mobile hotspot, investigate firewall policy, NAT traversal, address conflicts and client routing as distinct possibilities. Do not claim that a single opened port resolves every IPsec architecture.

Troubleshoot routing and return traffic after security comes up

Suppose two sites use private prefixes 10.10.0.0/16 and 10.20.0.0/16 in a synthetic lab. If a gateway’s protected-domain policy omits the remote subnet or its route table sends traffic to the wrong next hop, a tunnel can appear established while users fail to reach the destination. Confirm the installed route for the exact target, the expected tunnel/interface selection and the traffic selectors that are negotiated. Avoid changing cryptographic settings when the packet never reaches the VPN processing path.

Return traffic is just as important. An internal server at the remote site may send replies through a different default gateway that does not know the initiating source network. That asymmetry can make the application fail after the original packet arrives correctly. Check the remote route back to the source and any stateful firewall policies along the path. A ping from the VPN gateway’s own address may not exercise the same protected source subnet as a user’s application session.

Overlapping address ranges create additional complications. Two remote-access users or two merged corporate networks might use the same private IPv4 space, making route and selector decisions ambiguous. A tunnel alone does not resolve address overlap. The architecture may need address planning, specific translation design or other approved approaches; editing a static route without understanding the duplicate ranges can redirect traffic to the wrong tenant or site.

Check security policy and observability without exposing secrets

Firewall rules should explicitly permit the intended VPN negotiation and protected data path while limiting unauthorized access. The rules depend on the chosen architecture, devices and transport. Security logs, association state, packet counters and appropriate captures can help distinguish a blocked negotiation from a data-path issue. A counter showing encrypted packets sent but no decrypted packets received suggests a different investigation from a tunnel that never negotiates.

Operational evidence must be collected carefully. VPN logs can contain peer identities, internal addresses and protocol details that belong in restricted incident records. Do not paste raw key material or sensitive configurations into a public learning platform or an unapproved AI service. For published examples, use reserved documentation IP ranges and synthetic names, and remove any embedded secrets from screenshots or command outputs.

The best incident record states when the tunnel was established, which source and destination were tested, what route was selected, whether a security policy matched and whether the return packet was observed. This narrows the problem without weakening the gateway’s cryptographic or access-control settings simply to make traffic pass.

Build a safe VPN comparison lab

Use a supported lab environment with two security gateways, protected test networks and a third segment representing the untrusted transport. Begin with a functioning site-to-site tunnel. Record the private prefixes, outer gateway addresses, negotiated state, route tables and a successful application test. Then introduce one controlled mismatch, such as a missing route or a protected-prefix selector that excludes the destination. Observe how tunnel state and data-path symptoms diverge.

For remote access, use a separately authorized test client and a synthetic user account, not an actual employee credential. Compare a policy that grants access to a single test subnet with one that intentionally denies the second. The exercise should show that connectivity is a result of both security association and authorization. If the simulator lacks IPsec features, treat the control-plane portion as conceptual and be explicit that no encrypted packets were actually verified.

Document restoration and cleanup so no insecure temporary gateway policy remains after testing. A lab that demonstrates a tunnel only by disabling firewall checks or using plaintext key storage teaches the wrong operational habit. Security training should show a working authorized connection whose restrictions are predictable and testable.

Tie VPN concepts to the applicable CCNA exam

CCNA v1.1 asks candidates to describe IPsec remote-access and site-to-site VPNs within its security fundamentals. Cisco’s announced v2.0 retains these concepts and specifically mentions protocols and transport modes. The distinction between a site-to-site topology and a transport-mode packet is therefore useful for version-accurate preparation, but the certification does not by itself imply professional competence to deploy all vendor VPN products.

The CCNA 200-301 page provides exam context, and the IPv4 subnetting foundation helps with protected prefix calculations. Consult Cisco’s v1.1 blueprint and v2.0 objectives to align study with the test date. A useful explanation ends with the original and outer packet paths, the intended protected network and the evidence that an authenticated tunnel also forwards only authorized traffic.