A Site-to-Site VPN is still the practical answer when two offices need secure, always-on network connectivity without paying for a private circuit. The setup is straightforward once you understand the moving parts: planning the subnets, matching IKE and IPsec settings, handling NAT correctly, and verifying that traffic really crosses the tunnel. This guide walks through that process on Cisco VPN routers and fits the hands-on networking skills covered in Cisco CCNA v1.1 (200-301).
Cisco CCNA v1.1 (200-301)
Learn essential networking skills and gain hands-on experience in configuring, verifying, and troubleshooting real networks to advance your IT career.
Get this course on Udemy at the lowest price →Quick Answer
A Site-to-Site VPN creates an encrypted tunnel between two networks over the public internet so branch offices, shared services, and partner sites can communicate securely. On Cisco VPN routers, the key work is matching IKE and IPsec settings, exempting VPN traffic from NAT, adding the right routes, and verifying that both sides can pass traffic in both directions as of September 2026.
Quick Procedure
- Map both sites and confirm the public IPs, inside subnets, and outside interfaces.
- Plan the tunnel parameters, including IKE, IPsec, routing, and NAT exemption.
- Configure IKE Phase 1 on both Cisco routers with matching settings.
- Build the IPsec Phase 2 crypto map and apply it to the outside interface.
- Add routes or GRE over IPsec if you need dynamic routing or multiple subnets.
- Test with ping, traceroute, and Cisco verification commands.
- Troubleshoot IKE, IPsec, NAT, ACLs, and return routing if traffic fails.
| Topic | Site-to-Site VPN on Cisco VPN Routers |
|---|---|
| Primary Use Case | Always-on encrypted connectivity between branch offices, headquarters, and partner sites as of September 2026 |
| Core Protocols | IKE and IPsec |
| Common Design Choice | Static routing for simple sites; GRE over IPsec for multiple subnets or dynamic routing as of September 2026 |
| Key Risk Area | NAT, ACL mismatches, and return routing |
| Best Fit | Branch-to-headquarters, site-to-site partner links, and centralized application delivery |
What Is a Site-to-Site VPN?
A Site-to-Site VPN is a secure tunnel between two networks that sends traffic across the public internet as if the sites were directly connected. Instead of putting VPN software on every user laptop, you terminate the tunnel on routers or firewalls at each site.
This is why site-to-site designs remain common for branch offices, shared file servers, ERP systems, and partner connectivity. They are also a practical replacement for leased lines when you want lower cost, easier expansion, and encrypted transport without changing the way users access internal applications.
A site-to-site design is not about logging in one user at a time. It is about making two networks trust each other in a controlled, encrypted way.
A remote-access VPN is different because it connects one user device to the corporate network. A site-to-site VPN connects whole subnets, so it is the better choice when an office, lab, or service network needs always-on connectivity.
On Cisco routers, the classic building blocks are tunneling, Encryption, and Authentication. The tunnel carries traffic, encryption protects confidentiality, and authentication proves the peers are really who they claim to be.
How Does a Site-to-Site VPN Work?
A site-to-site VPN works by building a control channel first, then using that channel to protect data traffic. On Cisco VPN routers, the usual sequence is IKE Phase 1 to create the secure management association, then IPsec Phase 2 to encrypt the actual payload between the local and remote subnets.
IKE is Internet Key Exchange, the negotiation process that lets two peers agree on how to trust each other. IPsec is the security framework that encrypts and integrity-protects the traffic after the tunnel is established. If those two pieces do not match on both ends, the tunnel will not come up cleanly.
Note
For a deeper protocol reference, Cisco’s official guidance on VPN and IOS features is the safest source to follow when you are matching router behavior to current software releases. See Cisco and the Cisco Learning Network for current platform documentation and configuration concepts.
When GRE over IPsec Makes Sense
GRE over IPsec is useful when you need more than one subnet across the tunnel or want to run dynamic routing protocols over the link. Plain IPsec with crypto maps works well for simple designs, but GRE adds a virtual point-to-point interface that is easier to route through when the topology grows.
If you are carrying multiple VLANs, running OSPF across sites, or expecting the remote network to change often, GRE over IPsec gives you more flexibility. The tradeoff is extra overhead and slightly more configuration, so it is usually reserved for networks that need routing intelligence rather than a single static subnet path.
In simple terms, use plain site-to-site IPsec when you want a secure link between two known subnets. Use GRE over IPsec when you want that secure link plus routing flexibility.
Prerequisites
Before you touch the Cisco configuration, make sure the physical and administrative pieces are ready. Most VPN failures are not caused by exotic crypto problems. They are caused by missing access, wrong interface addresses, or a bad assumption about the WAN path.
- Two Cisco VPN routers with outside interfaces that can reach the public internet.
- Administrator access on both routers, plus console access in case remote changes lock you out.
- Inside and outside IP addressing documented for both sites.
- A rollback plan with a saved configuration backup before changes begin.
- Knowledge of the local and remote subnets so you can avoid overlap.
- Access to upstream firewall or ISP settings in case IKE or IPsec is filtered.
- Basic Cisco IOS command familiarity, especially show and debug commands.
For network design and operating procedures, align your thinking with Cisco’s own platform guidance and with the skills emphasized in Cisco CCNA v1.1 (200-301). That matters because a VPN is never just “crypto.” It is routing, interface placement, ACLs, and operational troubleshooting working together.
If your organization follows formal control frameworks, the design should also support least privilege and segmentation principles. NIST guidance on secure network architecture is a strong reference point, especially when you are deciding what subnets should and should not traverse the tunnel. See NIST for current security guidance and network hardening references.
How Do You Plan a Cisco Site-to-Site VPN?
Planning is where most successful VPN projects are won. If you know the public IPs, private subnets, NAT behavior, and routing model before configuration begins, the actual setup is usually routine.
Start by identifying both endpoints clearly. Write down the local subnet, the remote subnet, the router outside interface, the default gateway, and the public IP on each side. If either site sits behind another firewall or ISP device, document that too, because the VPN peer may not be the device you first expect.
Check the Addressing and Topology First
Confirm that the internal subnets do not overlap. A branch office using 192.168.1.0/24 when headquarters already uses that same range is a classic problem, because routing decisions become ambiguous and security policies get messy.
Also confirm that the outside interfaces can reach each other over the internet. If a basic ping to the peer public address does not work, there is no point debugging IPsec yet. Fix the path first, then the tunnel.
Decide on Routing and NAT Early
Simple point-to-point site-to-site VPNs often use static routes. More complex designs may need dynamic routing, and GRE over IPsec becomes attractive when you want to advertise multiple routes or tolerate frequent network changes.
NAT deserves special attention. VPN traffic should usually bypass NAT when it is destined for the remote protected subnet, or the tunnel may form but the data packets will be translated incorrectly. That is one of the most common reasons a tunnel appears healthy while applications still fail.
For policy and traffic filtering concepts, compare the role of VPN matching ACLs with the role of firewall ACLs. They are not the same thing. One selects interesting traffic for encryption, while the other decides what is allowed through a security boundary.
How Do You Configure IKE Phase 1 on Cisco VPN Routers?
IKE Phase 1 is the step that creates the secure control channel between the two Cisco routers. It is where the peers prove identity and agree on how they will protect the rest of the negotiation.
On both routers, the IKE policy must match on the settings that matter: encryption, hash, authentication method, Diffie-Hellman group, and lifetime. If one side uses SHA-256 and the other expects SHA-1, or if the pre-shared key does not match, the tunnel will fail before IPsec ever starts.
- Define the IKE policy. Choose the same encryption, hashing, authentication, DH group, and lifetime on each router. Exact syntax varies by IOS version, but the logic does not.
- Set the pre-shared key. For labs and small environments, pre-shared keys are common because they are simple and quick to validate. Larger environments often use certificates for stronger identity management.
- Identify the peer address. Make sure each router knows the public IP of the opposite side. A wrong peer address often looks like a crypto problem when it is really just a bad destination.
- Apply the policy consistently. Both ends must mirror one another closely. Small mismatches cause negotiation failure, and the logs usually tell you which parameter disagreed.
As of September 2026, Cisco and industry security guidance continue to favor stronger encryption and modern hash choices over outdated legacy settings. Do not design a new VPN around weak defaults just because an old lab document showed them.
For configuration syntax and platform behavior, always cross-check against official vendor documentation. Cisco’s current documentation and learning material are the right baseline for router-specific settings and supported features, including crypto map behavior and IKE negotiation details. See Cisco.
How Do You Configure IPsec Phase 2 and the Crypto Map?
IPsec Phase 2 is the step that protects the actual user traffic crossing the tunnel. Once IKE Phase 1 creates trust between the peers, Phase 2 negotiates how packets will be encrypted and verified end to end.
The transform set defines the security algorithms used for the data plane. The crypto map ties together the peer address, transform set, and traffic selectors that say which packets should enter the tunnel. On Cisco routers, applying that crypto map to the correct outside interface is critical. If you attach it to the wrong interface, the tunnel may never activate for real traffic.
- Create the transform set. Match encryption and integrity settings on both routers so the peers agree on the same IPsec proposal.
- Define the interesting traffic ACL. Build an access control list that matches only the local subnet to the remote subnet. This ACL tells the router what should be encrypted.
- Build the crypto map. Add the peer, the transform set, and the ACL to the map so the router knows how to build the IPsec SA.
- Apply the crypto map to the outside interface. This is the point where the router starts using the policy for outbound traffic on that WAN-facing interface.
- Mirror the configuration on the remote router. Both sides must agree on the same traffic selectors and security settings or packets will be dropped.
A tunnel can be “up” from a negotiation standpoint while still blackholing traffic if Phase 2 parameters do not align with the real subnets being used. That is why you always test with actual application traffic, not just a successful handshake.
NIST’s cybersecurity guidance is useful here because it reinforces minimizing exposure. Encrypt only what needs to cross the tunnel, and do not widen the ACL just because it is easier to configure. See NIST for secure design principles that map well to VPN segmentation.
How Do You Handle Routing Between the Two Sites?
Routing determines what actually enters the tunnel. If the router does not know how to reach the remote subnet, encrypted connectivity will not matter because packets will never be forwarded correctly.
In small site-to-site designs, static routes are often the cleanest choice. You add a route for the remote subnet pointing toward the tunnel path or the appropriate next hop, and the router forwards matching traffic into the VPN. For two fixed sites, this is usually simple and reliable.
When the environment grows, static routing becomes less attractive. If you have multiple branches, frequent subnet changes, or a need to advertise routes dynamically, GRE over IPsec gives you a better routing foundation. It is not always necessary, but it solves real operational problems when the design gets bigger.
Verify Return Routing
Return traffic matters as much as the outbound path. A ping from headquarters to the branch may succeed while the reverse direction fails if the branch router does not know how to send responses back through the tunnel.
After the tunnel comes up, check the route table on both routers and confirm the next-hop decision for each protected subnet. If needed, use traceroute from inside hosts to confirm the path is symmetric and not being diverted to a default internet route.
Dynamic Routing is often the better choice once multiple routers, branches, or route changes enter the picture. Static routing is simpler. Dynamic routing is more scalable. The right answer depends on how often the topology changes and how much operational overhead your team can support.
How Do You Handle NAT, ACLs, and Traffic Exemptions?
NAT can break a VPN in a subtle way. If the router translates traffic that should have remained untouched for the tunnel, IPsec selectors no longer match and the encrypted packet flow fails.
The fix is usually NAT exemption or NAT bypass for traffic headed toward the remote protected network. In other words, when source traffic from the local subnet is destined for the remote subnet, it should be exempted from translation before the VPN policy sees it.
- Match only the intended subnets. Keep the VPN ACL narrow so it covers the exact source and destination networks.
- Place NAT exemption correctly. NAT order matters, and a broad translation rule can override the exemption if it is written poorly.
- Separate policy roles. VPN ACLs identify interesting traffic; firewall ACLs enforce security policy. Do not assume they do the same job.
- Check ACL direction. A reversed source and destination statement is enough to stop negotiation or data flow.
Incorrect ACLs are one of the most common causes of a tunnel that comes up but passes no data. The routers may authenticate successfully, yet they will never encrypt the traffic you actually care about because the selectors do not match the real packet flow.
For a security reference point, the CIS Benchmarks and CIS Controls are useful when you are tightening edge policy and reducing unnecessary exposure across the VPN. They reinforce a simple rule: allow only what the business needs.
How Do You Test the Tunnel and Verify Traffic Flow?
Testing should happen in layers. Start with the physical interface, then the IKE association, then the IPsec security association, and only then move to application traffic. That order saves time because it tells you exactly where the break occurs.
- Check interface status. Confirm the outside interface is up/up and has the correct IP address.
- Verify IKE negotiation. Look for the Phase 1 security association and confirm the peer is recognized.
- Verify IPsec SAs. Confirm the data-plane association is established and packet counters are incrementing.
- Test with ping and traceroute. Use inside-to-inside testing, not just router-to-router probes.
- Validate application access. Open a file share, web app, or other real service that should cross the tunnel.
On Cisco routers, the exact verification commands depend on the IOS release, but the logic stays the same: confirm the peer, confirm the SA state, and confirm packet counters move when you generate traffic. If the tunnel establishes but counters stay at zero, the traffic selectors, routes, or NAT rules are usually wrong.
Pro Tip
Always test both directions. A one-way success can hide return-routing problems, ACL gaps, or asymmetric NAT behavior that will surface later during production use.
For current platform behavior and router command guidance, Cisco’s official documentation is the best source to validate what you see on the device. See Cisco for IOS and VPN feature references.
How Do You Troubleshoot Common Cisco VPN Problems?
Most Cisco VPN problems fit into a short list: mismatched parameters, bad peer addresses, incorrect pre-shared keys, broken NAT exemption, missing routes, and ACL mistakes. The challenge is not identifying the category. The challenge is proving which one caused the failure.
If IKE does not establish, suspect the control plane first. If IKE comes up but IPsec does not, look at Phase 2 settings and traffic selectors. If both security associations exist but users still cannot reach the remote subnet, focus on routing and NAT.
- Check physical and upstream connectivity. Make sure the router can reach the remote public IP and that no firewall or ISP device is blocking UDP 500, UDP 4500, or ESP where applicable.
- Verify IKE parameters. Confirm policy, pre-shared key, and peer address on both sides.
- Check IPsec selectors. Make sure the ACL matches the real source and destination subnets.
- Review NAT rules. Confirm that VPN traffic is exempted and not being translated before encryption.
- Validate return routing. Confirm the remote site knows how to send responses back through the tunnel.
Common symptoms tell a story. Tunnel flapping often points to unstable reachability or a parameter mismatch that repeatedly renegotiates. One-way traffic usually means return routing or ACL problems. IKE up, IPsec down usually means Phase 2 or traffic-selector issues.
For threat and operational context, the Verizon Data Breach Investigations Report and MITRE ATT&CK are useful references when you want to understand how network segmentation and tunnel exposure fit into broader defensive practice. See Verizon DBIR and MITRE ATT&CK.
What Are the Current Best Practices for Site-to-Site VPNs?
The best practice is to keep the tunnel simple, narrow, and monitored. That means stronger encryption settings, tight ACL scope, clear routing, and a change process that preserves a known-good backup of the router configuration.
As of September 2026, modern deployments should avoid weak or outdated choices just because they still appear in old lab notes. Use stronger crypto where supported, keep authentication disciplined, and review Cisco’s current guidance before copying older examples into production.
- Limit exposure. Only permit the specific subnets and services that the business actually needs.
- Monitor tunnel health. Watch for SA drops, packet counter stalls, and interface changes.
- Back up configurations. Save router configs before and after change windows.
- Document the design. Record peer IPs, subnets, NAT rules, and crypto parameters.
- Use change control. A small ACL edit can break an otherwise stable tunnel.
For workforce and operational alignment, the NICE/NIST Workforce Framework is helpful when you assign VPN administration, monitoring, and incident response duties. It reinforces the idea that secure network changes should be owned, documented, and reviewed, not improvised during an outage.
See NICE/NIST Workforce Framework for role alignment and task references that map well to network operations and security administration.
When Should You Use a Site-to-Site VPN Instead of Remote Access?
Use a site-to-site VPN when an entire location, service network, or partner environment needs persistent connectivity. Use remote access when individual users need secure access from home, travel, or unmanaged endpoints.
A branch office with printers, servers, IP phones, and local workstations is a strong site-to-site candidate. A consultant on the road with a laptop is a remote-access candidate. Mixing those use cases creates unnecessary complexity and usually makes support harder.
Site-to-site VPNs are also a reasonable replacement for private circuits when you want lower cost and easier scaling. If the business can tolerate internet dependency and you can manage the security controls, the VPN is often the more practical answer.
That said, not every topology belongs in a simple two-router design. Cloud connectivity, multiple routes, and larger hub-and-spoke deployments may call for more advanced routing or firewall-based designs. The “right” architecture depends on the number of sites, the application traffic pattern, and the operational support model.
For workforce and deployment trends, the U.S. Bureau of Labor Statistics continues to show steady demand for network and security-related roles, which is one reason practical VPN skills still matter. See BLS Occupational Outlook Handbook for current role outlooks and growth data.
Key Takeaway
Site-to-Site VPNs solve a network-to-network problem, not a user-to-network problem.
IKE Phase 1 must match on both Cisco routers or the tunnel will not form.
IPsec Phase 2 protects the traffic, but only if the ACLs and subnets are correct.
NAT exemption and return routing are the two checks most likely to prevent “up but no traffic” failures.
GRE over IPsec is worth considering when you need dynamic routing or multiple subnets across the tunnel.
Cisco CCNA v1.1 (200-301)
Learn essential networking skills and gain hands-on experience in configuring, verifying, and troubleshooting real networks to advance your IT career.
Get this course on Udemy at the lowest price →Conclusion
Setting up a Cisco Site-to-Site VPN is mostly about disciplined planning and verification. If you map both sites correctly, match IKE and IPsec settings, exempt the right traffic from NAT, and confirm routing in both directions, the tunnel will usually be stable and predictable.
The real skill is not just getting the tunnel to form. It is knowing how to prove that the right traffic crosses it, how to spot a NAT or ACL mistake quickly, and how to troubleshoot the control plane before you waste time on the wrong layer. That is practical networking work, and it aligns well with Cisco CCNA v1.1 (200-301) concepts.
If you are building this in a lab or preparing for production, use Cisco’s official documentation, verify the configuration with real traffic, and keep the design as simple as the use case allows. Careful design and methodical testing are what turn a VPN from a fragile setup into a secure, reliable connection between sites.
CompTIA®, Cisco®, Microsoft®, AWS®, EC-Council®, ISC2®, ISACA®, and PMI® are trademarks of their respective owners.
