Remote Access and Site-to-Site VPNs Explained

Imagine two office buildings on opposite sides of a city that need to share files as if they were on the same local network — or an employee working from a coffee shop who needs to securely reach internal company servers. Both scenarios rely on Virtual Private Networks (VPNs).

A VPN creates an encrypted “tunnel” across an untrusted network (usually the public internet), making it appear as though devices are directly connected to a private network, even though their traffic is physically traveling across shared infrastructure.

There are two primary VPN architectures:

1. Remote Access VPN — connects an individual device (like a laptop) to a private network.
2. Site-to-Site VPN — connects two entire networks (like two office branches) to each other.

This article explains both from first principles, covers the underlying protocols, and walks through real configuration examples.

1. The Core Idea: Tunneling and Encryption

A VPN relies on two fundamental concepts:

• Tunneling: Encapsulating one packet inside another, so private network traffic can travel across a public network without being exposed to it directly.
• Encryption: Scrambling the tunneled data so that even if someone intercepts it, they cannot read it.

flowchart LR
    A[Private Data] --> B[Encryption]
    B --> C[Encapsulation - New Outer Header]
    C --> D[Internet / Public Network]
    D --> E[De-encapsulation]
    E --> F[Decryption]
    F --> G[Original Private Data Delivered]

Without a VPN, your data travels across the internet in a form that intermediate routers, ISPs, or attackers on shared networks (like public Wi-Fi) could potentially read. A VPN wraps that data in an encrypted “envelope” so only the intended destination can open it.

2. Remote Access VPN

A Remote Access VPN allows an individual user’s device to securely connect into a private network from anywhere — home, a hotel, an airport — as if they were physically plugged into the office network.

2.1 How It Works

1. The user runs VPN client software (e.g., Cisco AnyConnect, OpenVPN, WireGuard) on their laptop or phone.
2. The client authenticates to a VPN gateway/concentrator at the edge of the corporate network (often combined with AAA/MFA, as covered in AAA concepts).
3. Once authenticated, the client is assigned a virtual IP address from the corporate network’s address pool.
4. All (or specified) traffic from the client is encrypted and tunneled to the gateway, which decrypts it and forwards it into the internal network.

sequenceDiagram
    participant Laptop as Remote Employee Laptop
    participant Internet
    participant GW as VPN Gateway (Corporate HQ)
    participant Server as Internal File Server
    Laptop->>GW: Establish encrypted tunnel (IPsec/TLS)
    GW-->>Laptop: Assign virtual internal IP
    Laptop->>GW: Encrypted request for Server
    GW->>Server: Decrypted request forwarded internally
    Server-->>GW: Response
    GW-->>Laptop: Encrypted response

2.2 Common Remote Access VPN Technologies

2.3 Split Tunneling vs Full Tunneling

3. Site-to-Site VPN

A Site-to-Site VPN connects two or more entire networks together — for example, a company’s headquarters and a branch office — so devices on either side can communicate as though they were on the same LAN, without individual users needing VPN client software.

3.1 How It Works

1. A VPN tunnel is established between two VPN gateways — typically routers or firewalls — one at each site.
2. The gateways negotiate encryption keys (commonly via IKE — Internet Key Exchange).
3. Traffic destined for the remote site’s subnet is automatically encrypted, encapsulated, and sent through the tunnel — transparent to end users and devices.

flowchart LR
    subgraph HQ["Headquarters - 10.1.0.0/16"]
        A[Internal Hosts] --> GW1[VPN Gateway/Router A]
    end
    subgraph Branch["Branch Office - 10.2.0.0/16"]
        GW2[VPN Gateway/Router B] --> B[Internal Hosts]
    end
    GW1 <--Encrypted IPsec Tunnel over Internet--> GW2

3.2 IPsec: The Foundation of Site-to-Site VPNs

Most site-to-site VPNs use the IPsec (Internet Protocol Security) suite, which operates in two phases:

IKE Phase 1 — establishes a secure, authenticated channel between the two gateways (the “control channel”):

• Negotiates encryption/hashing algorithms
• Authenticates gateways (pre-shared key or certificates)
• Establishes an ISAKMP/IKE Security Association (SA)

IKE Phase 2 — negotiates the actual IPsec SA used to encrypt real data traffic, using keys derived from Phase 1.

3.3 IPsec Protocol Components

4. Remote Access vs Site-to-Site VPN Comparison

5. Configuration Examples

5.1 Cisco IOS: Site-to-Site IPsec VPN (Router A — HQ)

! Step 1: Define ISAKMP (IKE Phase 1) policy
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400

! Step 2: Define pre-shared key for the remote peer
crypto isakmp key MySharedVpnKey123 address 203.0.113.2

! Step 3: Define IPsec transform set (Phase 2 encryption)
crypto ipsec transform-set MY-TSET esp-aes 256 esp-sha256-hmac

! Step 4: Define interesting traffic (what gets encrypted)
access-list 101 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255

! Step 5: Create the crypto map tying it all together
crypto map VPN-MAP 10 ipsec-isakmp
 set peer 203.0.113.2
 set transform-set MY-TSET
 match address 101

! Step 6: Apply crypto map to the outbound WAN interface
interface GigabitEthernet0/0
 ip address 203.0.113.1 255.255.255.252
 crypto map VPN-MAP

! Step 1: Define ISAKMP (IKE Phase 1) policy
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400

! Step 2: Define pre-shared key for the remote peer
crypto isakmp key MySharedVpnKey123 address 203.0.113.2

! Step 3: Define IPsec transform set (Phase 2 encryption)
crypto ipsec transform-set MY-TSET esp-aes 256 esp-sha256-hmac

! Step 4: Define interesting traffic (what gets encrypted)
access-list 101 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255

! Step 5: Create the crypto map tying it all together
crypto map VPN-MAP 10 ipsec-isakmp
 set peer 203.0.113.2
 set transform-set MY-TSET
 match address 101

! Step 6: Apply crypto map to the outbound WAN interface
interface GigabitEthernet0/0
 ip address 203.0.113.1 255.255.255.252
 crypto map VPN-MAP

The matching configuration on the branch router (Router B) would mirror this, with peer/local addresses and subnets reversed.

5.2 Cisco AnyConnect (Remote Access VPN, ASA Simplified)

! Enable SSL VPN (WebVPN) on the outside interface
webvpn
 enable outside
 anyconnect image disk0:/anyconnect-win.pkg
 anyconnect enable

! Define a group policy
group-policy REMOTE-USERS internal
group-policy REMOTE-USERS attributes
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT-ACL

! Define local address pool for VPN clients
ip local pool VPN-POOL 10.50.50.10-10.50.50.100 mask 255.255.255.0

! Enable SSL VPN (WebVPN) on the outside interface
webvpn
 enable outside
 anyconnect image disk0:/anyconnect-win.pkg
 anyconnect enable

! Define a group policy
group-policy REMOTE-USERS internal
group-policy REMOTE-USERS attributes
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT-ACL

! Define local address pool for VPN clients
ip local pool VPN-POOL 10.50.50.10-10.50.50.100 mask 255.255.255.0

5.3 Linux: Site-to-Site VPN with StrongSwan (IPsec)

sudo apt install strongswan -y

sudo apt install strongswan -y

# /etc/ipsec.conf
conn site-to-site
    left=203.0.113.1
    leftsubnet=10.1.0.0/16
    right=203.0.113.2
    rightsubnet=10.2.0.0/16
    ike=aes256-sha256-modp2048
    esp=aes256-sha256
    keyexchange=ikev2
    authby=secret
    auto=start

# /etc/ipsec.conf
conn site-to-site
    left=203.0.113.1
    leftsubnet=10.1.0.0/16
    right=203.0.113.2
    rightsubnet=10.2.0.0/16
    ike=aes256-sha256-modp2048
    esp=aes256-sha256
    keyexchange=ikev2
    authby=secret
    auto=start

# /etc/ipsec.secrets
203.0.113.1 203.0.113.2 : PSK "MySharedVpnKey123"

# /etc/ipsec.secrets
203.0.113.1 203.0.113.2 : PSK "MySharedVpnKey123"

sudo systemctl restart strongswan
sudo ipsec statusall

sudo systemctl restart strongswan
sudo ipsec statusall

5.4 Linux: Remote Access VPN with WireGuard

sudo apt install wireguard -y
wg genkey | tee privatekey | wg pubkey > publickey

sudo apt install wireguard -y
wg genkey | tee privatekey | wg pubkey > publickey

# /etc/wireguard/wg0.conf (Server/Gateway side)
[Interface]
PrivateKey = <server-private-key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.8.0.2/32

# /etc/wireguard/wg0.conf (Server/Gateway side)
[Interface]
PrivateKey = <server-private-key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.8.0.2/32

sudo wg-quick up wg0
sudo wg show

sudo wg-quick up wg0
sudo wg show

5.5 Python: Testing VPN Tunnel Reachability

A simple script to confirm a remote site’s internal subnet is reachable through a site-to-site VPN tunnel:

import subprocess

def check_vpn_reachability(remote_ip):
    result = subprocess.run(
        ["ping", "-c", "4", remote_ip],
        capture_output=True, text=True
    )
    if "0% packet loss" in result.stdout:
        print(f"VPN tunnel healthy: {remote_ip} reachable")
    else:
        print(f"VPN tunnel issue: {remote_ip} unreachable")
        print(result.stdout)

check_vpn_reachability("10.2.0.1")  # Branch office gateway

import subprocess

def check_vpn_reachability(remote_ip):
    result = subprocess.run(
        ["ping", "-c", "4", remote_ip],
        capture_output=True, text=True
    )
    if "0% packet loss" in result.stdout:
        print(f"VPN tunnel healthy: {remote_ip} reachable")
    else:
        print(f"VPN tunnel issue: {remote_ip} unreachable")
        print(result.stdout)

check_vpn_reachability("10.2.0.1")  # Branch office gateway

6. Real-World Example: Hybrid Corporate Network

A retail company has:

• Headquarters in New York running the main ERP system.
• 10 branch stores across the country needing constant access to inventory and POS systems at HQ — connected via site-to-site IPsec VPNs on their edge routers, so store devices reach HQ servers transparently.
• 50 remote sales employees who travel and need occasional secure access to internal CRM tools from hotels and airports — using a Remote Access SSL VPN client on their laptops.

This hybrid approach is extremely common: site-to-site VPNs for fixed locations, remote access VPNs for mobile individuals.

7. Best Practices

• Use strong, modern encryption (AES-256, SHA-256/384) — avoid outdated DES/3DES and MD5.
• Prefer certificate-based authentication over pre-shared keys for site-to-site VPNs at scale; PSKs are simpler but harder to rotate securely.
• Combine remote access VPNs with MFA (see AAA article) to prevent credential-based compromise.
• Use split tunneling carefully — full tunneling gives better visibility and control but costs more bandwidth centrally.
• Monitor VPN tunnel status continuously; configure alerting for tunnel drops.
• Regularly rotate pre-shared keys and certificates.
• Document and review crypto map / IKE policies periodically — deprecated algorithms (like DES, MD5, DH group 1/2) should be phased out.
• Segment VPN-connected networks with firewalls/ACLs rather than granting full flat-network access — apply least privilege even across VPN tunnels.

8. Troubleshooting VPN Issues

Cisco debug and verification commands:

show crypto isakmp sa
show crypto ipsec sa
debug crypto isakmp
debug crypto ipsec

show crypto isakmp sa
show crypto ipsec sa
debug crypto isakmp
debug crypto ipsec

StrongSwan verification:

sudo ipsec statusall
sudo journalctl -u strongswan -f

sudo ipsec statusall
sudo journalctl -u strongswan -f

9. Summary

• Remote Access VPNs connect individual users to a private network — ideal for traveling or work-from-home employees.
• Site-to-Site VPNs connect entire networks together — ideal for branch offices and data centers.
• Both rely on tunneling and encryption, most commonly through the IPsec protocol suite (IKE Phase 1/2, ESP/AH), though modern alternatives like WireGuard are gaining popularity for their simplicity and performance.

Understanding the distinction — and how each is configured and troubleshooted in real environments — is fundamental for any network engineer or security professional.

10. Deep Dive: MPLS vs VPN for Site Interconnection

Site-to-site VPNs over the public internet aren’t the only way to connect branch offices. Many organizations, especially larger enterprises, use MPLS (Multiprotocol Label Switching) provided by a carrier as an alternative or complement to IPsec VPNs.

Many enterprises adopt a hybrid model called SD-WAN (Software-Defined WAN), which intelligently routes traffic across a mix of MPLS, broadband internet with IPsec VPN, and even LTE/5G backup links, dynamically choosing the best path per application based on real-time performance metrics — effectively automating the trade-offs listed above rather than forcing a single static choice.

11. Deep Dive: GRE over IPsec

A pure IPsec tunnel has a limitation: it only encrypts unicast IP traffic matching the “interesting traffic” ACL, and doesn’t natively support multicast or dynamic routing protocol traffic (like OSPF or EIGRP) between sites. GRE (Generic Routing Encapsulation) solves this by creating a simple, protocol-agnostic tunnel that can carry any traffic type — including routing protocol updates and multicast — which is then wrapped inside an IPsec tunnel for encryption.

! Simplified Cisco GRE over IPsec configuration snippet
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel protection ipsec profile GRE-PROFILE

! Simplified Cisco GRE over IPsec configuration snippet
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel protection ipsec profile GRE-PROFILE

This combination — GRE for flexible encapsulation, IPsec for encryption — is extremely common in enterprise WANs that need dynamic routing protocols to run natively across the VPN, automatically adjusting paths if a link fails, rather than relying on static routes alone.

12. Deep Dive: Zero Trust and the Decline of “Full Network Access” VPNs

Traditional remote access VPNs, once connected, often grant broad access to an entire internal network segment — a model increasingly viewed as risky, since a single compromised laptop can become a launching point for lateral movement across the whole corporate network. The Zero Trust Network Access (ZTNA) model is emerging as a modern alternative/complement to traditional VPNs.

Key differences:

Many organizations are transitioning critical application access to ZTNA models while retaining traditional site-to-site VPNs for bulk network interconnection where full ZTNA-style per-application brokering isn’t yet practical — again showing that these aren’t mutually exclusive approaches but complementary tools chosen based on the specific access scenario.

13. Common Misconceptions

• “A VPN makes me completely anonymous online.” A VPN encrypts and reroutes your traffic through the VPN gateway, but the VPN provider (or your employer, for a corporate VPN) can still see your traffic; it is not the same as anonymity.
• “Site-to-site VPNs don’t need strong encryption since it’s ‘just between our own offices.’ Traffic still traverses the public internet between the two gateways, exactly like any other internet traffic, and is just as interceptable if not properly encrypted with strong, modern algorithms.
• “Once the VPN tunnel is up, my job is done.” Tunnel state must be actively monitored — a tunnel can silently drop key negotiation on rekey, quietly leaving the site disconnected until someone notices application failures.
• “WireGuard is less secure because it’s newer and simpler than IPsec.” WireGuard’s simplicity is an intentional design choice, using a small, modern, well-audited cryptographic codebase; its reduced complexity is widely regarded by cryptographers as a security strength rather than a weakness, reducing the attack surface compared to IPsec’s much larger and more complex specification.

Further Reading

• RFC 4301 — Security Architecture for IP (IPsec)
• Cisco Site-to-Site IPsec VPN Configuration Guide
• WireGuard Official Documentation
• StrongSwan Documentation
• Cisco AnyConnect Configuration Guide
• NIST Guide to IPsec VPNs (SP 800-77)