A virtual private network creates a protected path across an untrusted or shared network. However, site-to-site, remote-access, IPsec and SSL do not describe four completely separate technologies: the first two describe connection models, while IPsec and SSL or TLS describe security methods.
This distinction matters when designing, configuring or troubleshooting enterprise VPNs. A remote-access VPN can use IPsec or TLS, and a site-to-site VPN usually uses IPsec but can also use other secure tunnelling technologies.
What are the main types of VPN?
VPNs are mainly classified by who or what they connect. A site-to-site VPN connects networks through gateways, while a remote-access VPN connects an individual device to an organisation's network or applications.
| VPN term | What it describes | Typical endpoints | Common use |
|---|---|---|---|
| Site-to-site VPN | Connection model | Router, firewall or VPN gateway | Branch-to-head-office connectivity |
| Remote-access VPN | Connection model | User device and VPN gateway | Staff working from home or travelling |
| IPsec VPN | Encryption and tunnelling method | Gateways or individual clients | Network-layer secure connectivity |
| SSL VPN | Common name for a TLS-based VPN | Browser or VPN client and gateway | Secure application or remote network access |
The important design question is therefore not simply which of the four to choose. An engineer must first decide whether the requirement is network-to-network or user-to-network, and then select an appropriate security technology.
These design and implementation decisions are covered in practical enterprise routing and security labs within the CCNP Enterprise course.
How does a site-to-site VPN work?
A site-to-site VPN securely connects two or more networks through VPN gateways. Hosts normally send traffic without running VPN software because the routers or firewalls encrypt and decrypt packets on their behalf.
Consider a company with these networks:
- Chennai head office LAN:
10.10.0.0/16 - Bangalore branch LAN:
10.20.0.0/16 - Head office public IP:
203.0.113.1 - Branch public IP:
198.51.100.2
Diagram in words
Chennai PCs
10.10.0.0/16
|
Head-office VPN gateway
203.0.113.1
|
[Encrypted IPsec tunnel across the internet]
|
198.51.100.2
Branch VPN gateway
|
Bangalore PCs
10.20.0.0/16A packet from 10.10.10.25 to 10.20.20.50 reaches the head-office gateway. The gateway encrypts the original packet, adds an outer IP header containing the public gateway addresses and sends it across the internet. The branch gateway authenticates and decrypts it before forwarding the original packet to the destination.
Common site-to-site designs include:
- A single tunnel between two offices
- Hub-and-spoke tunnels connecting branches to a data centre
- Full-mesh connectivity between several sites
- Cloud VPN connections between an office and an AWS VPC or Azure virtual network
A provider-managed MPLS service can also connect sites, but MPLS does not automatically provide encryption. The difference between private forwarding and encryption is discussed further in MPLS labels, LSPs and service provider networks.
How does a remote-access VPN work?
A remote-access VPN connects an individual laptop, phone or workstation to protected resources. The user normally authenticates to a VPN gateway using a client application or web browser, often with multi-factor authentication.
Diagram in words
Remote laptop
Home or public internet
|
[Encrypted IPsec or TLS tunnel]
|
Enterprise VPN gateway
|
Internal DNS, applications and permitted subnetsAfter authentication, the client may receive a virtual IP address, DNS settings and routes. Access policies can then restrict the user to specific applications or networks.
Remote-access VPNs commonly operate in one of two routing modes:
| Mode | Behaviour | Main consideration |
|---|---|---|
| Full tunnel | Most or all client traffic passes through the organisation's gateway | Central inspection is possible, but gateway and internet bandwidth use increases |
| Split tunnel | Only selected enterprise prefixes use the VPN | Reduces VPN load, but policy and endpoint security require careful design |
A route such as 10.10.0.0/16 may be installed through the VPN adapter in split-tunnel mode, while ordinary internet traffic continues through the user's local router. An incorrect or missing client route is a common reason why authentication succeeds but internal applications remain unreachable.
What is an IPsec VPN?
An IPsec VPN protects IP packets at the network layer. It provides confidentiality through encryption, integrity checking, peer authentication and anti-replay protection.
Modern deployments commonly use IKEv2 to negotiate security associations and keys. The basic sequence is:
- The peers negotiate cryptographic algorithms and create an IKE security association.
- They authenticate each other using pre-shared keys or certificates.
- They negotiate IPsec child security associations for protected traffic.
- Encapsulating Security Payload, or ESP, protects the data packets.
- Keys and security associations are renewed according to configured lifetimes.
Common components include:
| Component | Purpose |
|---|---|
| IKEv2 | Negotiates parameters, authenticates peers and creates keys |
| ESP | Encrypts and authenticates user data |
| AES | Symmetric encryption algorithm |
| SHA-2 | Integrity algorithm used in relevant suites |
| Diffie-Hellman group | Supports secure shared-key establishment |
| NAT Traversal | Encapsulates ESP in UDP 4500 when NAT is detected |
IKE normally starts on UDP port 500. If NAT is detected, NAT Traversal generally uses UDP port 4500. Native ESP is IP protocol 50, not TCP or UDP port 50.
IPsec has two operating modes:
- Tunnel mode: Protects the entire original IP packet and adds a new outer IP header. This is typical for site-to-site VPNs.
- Transport mode: Protects the upper-layer payload while retaining the original IP header. It is used in specific host or tunnel-combination designs.
IPsec can support both site-to-site and remote-access VPNs. Route-based VPNs use logical tunnel interfaces, while policy-based VPNs select protected traffic through crypto ACLs or equivalent traffic selectors.
What is an SSL VPN?
An SSL VPN is the common industry name for a remote-access VPN built with TLS. SSL itself is obsolete, so current products should negotiate supported TLS versions rather than old SSL protocols.
TLS VPNs frequently use TCP port 443, which is usually permitted through internet firewalls and proxy environments. Some clients also use DTLS over UDP to avoid the performance problems that can occur when a TCP application is carried inside another TCP connection.
There are two broad forms:
- Clientless portal: A user signs in through a browser and accesses published web applications or selected services.
- Client-based tunnel: An installed client creates a virtual adapter and provides broader IP connectivity to approved networks.
TLS VPN does not mean that every authenticated user should receive unrestricted internal access. Secure deployments combine strong authentication, endpoint checks where appropriate, least-privilege authorisation, session logging and network segmentation. These controls also form part of the defensive skills developed in a Cybersecurity and SOC course.
How do IPsec and SSL VPNs compare?
IPsec is well suited to gateway-to-gateway tunnels and broad network-layer connectivity. TLS-based VPNs are commonly selected for user access because they can operate through browsers or managed clients over networks where TCP 443 is widely available.
| Feature | IPsec VPN | SSL or TLS VPN |
|---|---|---|
| Network layer | Layer 3 | Commonly application access or an IP tunnel over TLS/DTLS |
| Frequent use | Site-to-site and remote access | Primarily remote access |
| Typical protocols | IKEv2, ESP and NAT-T | TLS over TCP 443, sometimes DTLS |
| Client requirement | Gateway configuration or IPsec client | Browser or vendor client |
| Access scope | Often subnet or network based | Can be application-specific or network-wide |
| NAT handling | Uses NAT Traversal when required | Usually works easily through outbound web access |
| Common challenge | Proposal, identity or traffic-selector mismatch | Certificates, authentication, client policy or proxy issues |
Neither technology is automatically more secure. Security depends on protocol versions, algorithms, certificate or key management, authentication controls, software maintenance and access policy.
How do you configure a route-based IPsec VPN on Cisco IOS?
A route-based VPN places IPsec protection on a virtual tunnel interface, allowing routes to point towards that interface. The following head-office example uses IKEv2 and a pre-shared key; interface names and feature support must be checked for the actual IOS or IOS XE release.
crypto ikev2 proposal NR-PROP
encryption aes-cbc-256
integrity sha256
group 14
!
crypto ikev2 policy NR-POLICY
proposal NR-PROP
!
crypto ikev2 keyring NR-KEYRING
peer BRANCH
address 198.51.100.2
pre-shared-key local LAB-KEY-CHANGE-ME
pre-shared-key remote LAB-KEY-CHANGE-ME
!
crypto ikev2 profile NR-PROFILE
match identity remote address 198.51.100.2 255.255.255.255
identity local address 203.0.113.1
authentication remote pre-share
authentication local pre-share
keyring local NR-KEYRING
!
crypto ipsec transform-set NR-TS esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile NR-IPSEC
set transform-set NR-TS
set ikev2-profile NR-PROFILE
!
interface Tunnel10
ip address 10.255.0.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 198.51.100.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile NR-IPSEC
!
ip route 10.20.0.0 255.255.0.0 Tunnel10The branch requires mirrored peer settings, tunnel address 10.255.0.2/30 and a route for 10.10.0.0/16. Production deployments should use a securely generated secret or certificates, supported cryptographic algorithms, protected management access and a key-rotation process.
Generate traffic and verify the tunnel with:
show crypto ikev2 sa
show crypto ipsec sa
show interface Tunnel10
show ip route 10.20.20.50
ping 10.20.20.50 source 10.10.10.1A healthy IKEv2 security association should be in an established state. In show crypto ipsec sa, increasing encapsulation and decapsulation counters indicate bidirectional protected traffic. A tunnel interface can remain operational even when routing, return traffic or a remote security policy is incorrect, so interface state alone is not enough.
How do you troubleshoot a VPN that is not working?
Troubleshoot VPNs in layers: underlay reachability, negotiation, security associations, routing, policy and application behaviour. Avoid changing several settings at once because that makes the actual cause difficult to identify.
1. Verify internet or underlay reachability
Check whether each peer can reach the other's public address and whether the route uses the correct WAN interface.
show ip route 198.51.100.2
show ip interface brief
ping 198.51.100.2 source GigabitEthernet0/0A failed ping does not always prove the peer is down because ICMP may be filtered. Confirm that UDP 500, UDP 4500 and ESP are permitted where required.
2. Check IKE negotiation
show crypto ikev2 sa detail
show logging | include IKE|IPSECIf no IKE security association forms, compare peer addresses, identities, pre-shared keys, certificates, encryption algorithms, integrity settings and Diffie-Hellman groups. Also verify clock synchronisation when certificates are used.
3. Inspect IPsec counters
show crypto ipsec saCounters provide useful direction:
- Encapsulation increases but decapsulation remains zero: investigate the remote peer, return path and intermediate filtering.
- Decapsulation increases but the destination does not respond: inspect internal routing, host firewalls and access policies.
- Neither counter increases: check routes, traffic selectors and whether test traffic is entering the tunnel.
4. Verify routes in both directions
show ip route 10.20.0.0
show ip cef 10.20.20.50 detail
traceroute 10.20.20.50 source 10.10.10.1The remote site also needs a return route. Overlapping subnets, such as both locations using 192.168.1.0/24, prevent normal routing and may require renumbering or carefully designed NAT.
5. Check MTU and fragmentation
IPsec and TLS add headers, reducing the available payload size. If small pings work but large transfers fail, test packet sizes and Path MTU Discovery.
ping 10.20.20.50 size 1300 df-bit
ping 10.20.20.50 size 1400 df-bitDo not reduce MTU blindly. Confirm the failing size, check whether required ICMP messages are blocked and then adjust tunnel MTU or TCP MSS where the design requires it.
6. Use debugging carefully
debug crypto ikev2 protocol
undebug allDebugging can generate significant output on production equipment. Use logging filters, reproduce one test session and disable debugging immediately afterwards.
Which VPN type should you choose?
Choose according to the endpoints, required access and operational environment. Site-to-site IPsec is a strong default for connecting fixed networks, while a TLS or IPsec remote-access service suits individual users.
Use these questions during design:
- Are networks being connected, or individual users?
- Does the user need one application or broad IP connectivity?
- Will the connection pass through NAT, restrictive Wi-Fi or web proxies?
- Is full tunnelling required for inspection and compliance?
- Which authentication and multi-factor methods are supported?
- Who will manage certificates, keys, clients and software updates?
- Are high availability, dynamic routing and monitoring required?
For larger routed VPN designs, engineers may run OSPF or BGP over route-based tunnels, depending on platform support and policy. That introduces additional considerations such as route filtering, convergence, tunnel availability and recursive routing.
Summary
Site-to-site and remote-access describe the VPN connection model. IPsec and SSL or TLS describe technologies used to protect those connections.
- Site-to-site VPNs connect networks through gateways.
- Remote-access VPNs connect individual users or devices.
- IPsec commonly secures site-to-site and client VPN tunnels.
- SSL VPN normally means a modern TLS-based remote-access service.
- Successful troubleshooting requires checking underlay reachability, negotiation, routes, policies, counters and MTU.
To practise IKEv2, IPsec, routing and enterprise troubleshooting in guided labs, review the CCNP Enterprise course and request current batch details.
Reviewed by Network Rhinos networking trainers.
Related reading: QoS Basics: Classification, Queuing and Voice Traffic