First, the essential ideas
- VPN
- A virtual private network creates a logical private connection across another network. Here IPsec supplies selected IP-layer security services; the word VPN alone does not specify encryption or authorization.
- IPsec and security association
- IPsec is a family of IP security mechanisms. An IPsec security association, or SA, holds one direction's security parameters and keys. Two-way protected traffic normally needs an SA in each direction.
- IKEv2
- Internet Key Exchange version 2 authenticates peers and negotiates security parameters. Its IKE SA protects negotiation; Child SAs carry the negotiated IPsec traffic protection.
- ESP and AH
- Encapsulating Security Payload, ESP, can provide confidentiality and integrity. Authentication Header, AH, provides integrity and origin authentication but not confidentiality. The negotiated services matter.
- Tunnel and transport modes
- Tunnel mode protects an original IP packet inside a new outer IP header. Transport mode retains the original IP header and protects upper-layer content; the exact integrity coverage depends on the protocol.
- Traffic selector
- A traffic selector identifies traffic covered by a policy or negotiated SA using addresses and possibly protocols and ports. Matching a selector is not proof of successful cryptography.
- NAT traversal
- NAT traversal carries ESP inside UDP so address translators can handle it. Common IKE and NAT-traversal UDP ports are 500 and 4500; native ESP is IP protocol 50, not TCP port 50.
Begin with the original application's endpoints, not with a lock symbol. Write the inner source and destination first. Then identify the devices that add and remove protection. This separates a packet's destination from the gateways that carry it across the intervening network.
See the idea
Where gateway VPN protection begins and ends
The original hosts remain the endpoints; only the gateway-to-gateway segment receives this IPsec protection.
Select the original flow
Host-A sends to Host-B. Gateway-A checks the original addresses against policy before protecting the selected flow.
What this model leaves out: This is a logical tunnel-mode path, not the executed worksheet or a measured tunnel. Transit hops, routing details and application authorization are omitted.
Full visual explanation and references
Host-A connects to Gateway-A, which carries protected traffic to Gateway-B for delivery to Host-B. The two LAN segments are outside the gateway IPsec boundary.
This is a logical tunnel-mode path, not the executed worksheet or a measured tunnel. Transit hops, routing details and application authorization are omitted.
- Select the original flow
Host-A sends to Host-B. Gateway-A checks the original addresses against policy before protecting the selected flow.
datatracker.ietf.org - Carry the inner packet
ESP tunnel mode carries the original packet between the gateways. The outer header names Gateway-A and Gateway-B, not Host-B.
www.rfc-editor.org - Deliver after validation
Gateway-B validates and decapsulates, then forwards toward Host-B. That LAN leg and the server's permissions require separate controls.
datatracker.ietf.org
One idea at a time
Start with something familiar.
Draw Host-A, Gateway-A, Gateway-B and Host-B in that order. The two gateway WAN addresses identify the tunnel endpoints. The two host addresses remain the original communication endpoints. Do not replace the server's address with the VPN peer's address when describing the application.
Why learn this?
A tunnel can be established while a specific application still fails because of routes, selectors, firewall rules or server permissions. These are separate questions, and separate evidence prevents a green VPN status from ending the investigation too early.
An everyday comparison
Think of a sealed parcel carried between two company mailrooms. The delivery label on the parcel takes it to the other mailroom, while the envelope inside identifies the employee who ultimately receives it.
What happens in a network
In tunnel mode, the outer IP addresses reach the security gateways. The protected inner packet still names the original hosts. After validation and decapsulation, normal forwarding must deliver that packet to its final destination.
Where the comparison stopsAn envelope does not model cryptographic keys, anti-replay checks or authentication. Also, opening the outer parcel at the destination mailroom does not mean every employee may read every document.
Follow one worked example
- Name the original flow and the gateway pair.
Host-A 10.53.1.10 sends to Host-B 10.53.2.200. Gateway-A uses outer 192.0.2.1, while Gateway-B uses outer 198.51.100.1.
Why: Separating the two address pairs prevents confusion between reaching a peer and reaching the protected server.
- Evaluate the policy before assuming protection.
The intended selectors include both /24 LANs. Accidentally changing the remote range to /25 excludes Host-B's .200 address.
Why: An established negotiation channel cannot make a packet match a selector that excludes its destination.
- Ask for evidence at both ends.
In a real authorized lab, inspect negotiated SAs, selectors, outbound and inbound counters, and the actual application result. The offline model checks membership only.
Why: A one-sided counter or a boolean from Python does not establish two-way protected delivery.
Your first small task
Write two address pairs: original 10.53.1.10 to 10.53.2.200 and outer 192.0.2.1 to 198.51.100.1. Circle the original pair that belongs inside an ESP tunnel-mode packet. Then decide whether .200 is in 10.53.2.0/25.
Show a hint
A /25 beginning at .0 ends at .127. Do not test the gateway WAN address against the protected LAN selector.
Check the expected result
The host pair is the inner packet. The gateway pair is the outer header. The .200 host is outside the lower /25 range.
Pause and explain it in your own words
Does a valid IKE SA guarantee that Host-A can use Host-B's application?
Show a hint
Separate negotiation, traffic protection, routing and application authorization.
Show the explanation
No. The Child SA and traffic selectors may be wrong or absent, and routing, firewall policy or the application can still reject the flow. Inspect each layer with evidence from the same test.
Short answer
What should you understand today?
A site-to-site IPsec VPN protects selected traffic between gateways; remote access connects a user endpoint to a gateway. IKEv2 negotiates and authenticates, while IPsec SAs protect traffic. Tunnel mode adds an outer header; transport mode retains the original header. A working VPN does not grant unrestricted application trust.
Before you begin
Learning targets
- Recognize IPv4 prefixes, source and destination addresses, routes and ACL matching.
- For the optional executable model, use an offline Ubuntu 24.04 VM with Python 3.12 installed; no Cisco image is needed.
- Keep all example addresses synthetic and use no production VPN credentials, certificates or keys.
- Contrast gateway-to-gateway site-to-site protection with endpoint-to-gateway remote access.
- Explain IKEv2, directional IPsec SAs, ESP, AH, NAT traversal and the two modes.
- Trace the full Host-A to Host-B path and identify the protection boundary.
- Run or hand-trace an address-selector baseline, safe mismatch, repair and repeated checks.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
VPN
A virtual private network creates a logical private connection across another network. Here IPsec supplies selected IP-layer security services; the word VPN alone does not specify encryption or authorization.
IPsec and security association
IPsec is a family of IP security mechanisms. An IPsec security association, or SA, holds one direction's security parameters and keys. Two-way protected traffic normally needs an SA in each direction.
IKEv2
Internet Key Exchange version 2 authenticates peers and negotiates security parameters. Its IKE SA protects negotiation; Child SAs carry the negotiated IPsec traffic protection.
ESP and AH
Encapsulating Security Payload, ESP, can provide confidentiality and integrity. Authentication Header, AH, provides integrity and origin authentication but not confidentiality. The negotiated services matter.
Tunnel and transport modes
Tunnel mode protects an original IP packet inside a new outer IP header. Transport mode retains the original IP header and protects upper-layer content; the exact integrity coverage depends on the protocol.
Traffic selector
A traffic selector identifies traffic covered by a policy or negotiated SA using addresses and possibly protocols and ports. Matching a selector is not proof of successful cryptography.
NAT traversal
NAT traversal carries ESP inside UDP so address translators can handle it. Common IKE and NAT-traversal UDP ports are 500 and 4500; native ESP is IP protocol 50, not TCP port 50.
Two VPN arrangements with different endpoints
A site-to-site deployment places the IPsec function at gateways serving networks. Individual LAN hosts need not run a VPN client. Remote access instead terminates one side at a user's endpoint, often assigning it a virtual address and applying a user policy. Split tunneling sends only selected destinations through the VPN; full tunneling sends the policy's broader traffic set through it. Neither arrangement automatically authorizes all reachable resources.
- Identify who terminates protection before drawing its boundary.
- Remote-access VPN is not a synonym for unrestricted internal access.
Protocol names are not interchangeable
IKEv2 establishes authenticated negotiation and IPsec parameters; it is not the encrypted application payload protocol. ESP can combine encryption with integrity, including authenticated-encryption suites. AH authenticates selected packet content and appropriate header fields but does not hide the payload. Native ESP and AH have IP protocol numbers 50 and 51. IKE commonly uses UDP 500; NAT traversal commonly uses UDP 4500. Do not create a firewall rule for TCP port 50 and call it ESP.
- AH does not supply encryption and is problematic with address translation.
- This lesson identifies protocols; it does not recommend obsolete algorithm suites.
Modes change which header remains outside
With ESP tunnel mode, a new outer IP header carries a protected original IP packet between security endpoints. The original host addresses are inside the protected region when encryption is selected. ESP transport mode keeps the original IP header outside and protects upper-layer content. It is often associated with host-to-host protection, but deployment design determines the mode. Tunnel mode does not mean an application receives extra permission.
- Transport and tunnel are encapsulation modes, not stronger and weaker passwords.
- The unencrypted LAN portions remain outside this gateway-to-gateway IPsec boundary.
Associations and selectors need both directions
An IPsec SA is directional. A normal bidirectional conversation uses corresponding protected directions, while an IKE SA secures the negotiation exchanges. IKE_SA_INIT negotiates initial parameters and key exchange; IKE_AUTH authenticates and normally establishes the first Child SA. IKEv2 should not be described as literally using IKEv1 Phase 1 and Phase 2 packet exchanges. Negotiated traffic selectors determine which traffic is covered.
- A displayed SA is evidence about negotiated state, not every application's success.
- The reverse direction reverses source and destination roles; it does not reuse an outbound SA blindly.
Troubleshoot the path without broadening trust
Start with authorized evidence: endpoint addresses, route to the remote network, peer reachability, negotiation status and relevant logs. Then inspect negotiated selectors and matching encapsulation and decapsulation counters for a controlled flow. Check return routing and application authorization. Avoid solving a selector defect by permitting every network or weakening cryptography. Secrets, private keys and authentication material do not belong in shared troubleshooting notes.
- Record times and the precise tested flow so unrelated traffic does not confuse counters.
- Retest a permitted flow and an intentionally unauthorized flow after a repair.
Practice honestly at the available level
The lab below uses Python's standard address parser as a repeatable worksheet. It demonstrates prefix membership and labels headers; it does not implement ESP, AH or IKE. A practical next step is a separately authorized, crypto-capable CML or physical Cisco VPN lab with its release-specific guide, peer configuration and observed captures. CML reference-image rights do not automatically permit export to GNS3. This distinction is essential when reporting results.
- A paper trace is an available alternative when Python is unavailable.
- Keep the observed-model result separate from any future real-tunnel evidence.
Real-world walkthrough
A connected VPN with one unreachable server
In a fictional branch, an operator reports that the VPN is connected but a server moved from .100 to .200 is unreachable. Both addresses belong to the intended /24, yet a stale selector covers only the lower /25. The team initially considers changing authentication, although the symptom is specific to the server address.
- Record the old and new server addresses and preserve the approved /24 policy before making any edits.
- Compare both peers' negotiated traffic selectors, with local and remote understood from each peer's perspective.
- Check whether the new address is in the selected prefix; do not infer this from a tunnel status indicator.
- Reproduce the membership error offline, then propose the precise selector repair through the authorized change process.
- In a real lab or approved change, retest the intended application and a disallowed destination, then preserve both directions' evidence.
Guided GNS3 lab
Offline selector and header worksheet
Use a real local Python interpreter, or hand-trace the same expressions, to compare correct selectors with one safe prefix fault. No network traffic, cryptographic negotiation or successful tunnel is asserted.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| Host-A | eth0 (model) | 10.53.1.10/24; gateway 10.53.1.1 | Original source. |
| Gateway-A | LAN / WAN (model) | 10.53.1.1 / 192.0.2.1 | Logical local gateway and outer source. |
| Gateway-B | WAN / LAN (model) | 198.51.100.1 / 10.53.2.1 | Logical outer destination and remote gateway. |
| Host-B | eth0 (model) | 10.53.2.200/24; gateway 10.53.2.1 | Original destination; excluded by the fault. |
Set up the lab
- Disconnect the VM adapter. This exercise needs no network, root account, Cisco entitlement or third-party Python package.
- Open the VM console and Terminal. Enter shell commands only at the shell prompt and Python expressions only after starting the interpreter.
- Use synthetic address records, not real tunnel configuration or credentials. Save observations in private notes.
- With no interpreter, write each predicted value by hand and label the work paper-only; do not claim executed checks.
Open the offline interpreter
In the Ubuntu VM console, open Terminal. Check the installed interpreter version, then enter interactive Python. Keep this same session for the following steps and omit the displayed prompts.
python3 --version
python3What each command means
python3 --version- Confirm the local Python version; the specified platform supplies Python 3.12.
python3- Start the interactive interpreter; subsequent expressions are Python, not shell commands.
- What you should see
- Expect a version and an interactive prompt; record the actual version instead of inventing it.
- Why this step matters
- A known interpreter and continuous session make later variable-based tests reproducible.
Create the address records
At the Python prompt in the same VM terminal console, import the standard address parser and define both hosts and intended prefixes. These variables do not configure a network interface.
from ipaddress import ip_address, ip_network
a = ip_address('10.53.1.10')
b = ip_address('10.53.2.200')
local = ip_network('10.53.1.0/24')
remote = ip_network('10.53.2.0/24')What each command means
from ipaddress import ip_address, ip_network- Import standard-library parsers for addresses and network prefixes.
a = ip_address('10.53.1.10')- Store the original source address.
b = ip_address('10.53.2.200')- Store the original destination address.
local = ip_network('10.53.1.0/24')- Store Gateway-A's intended local selector.
remote = ip_network('10.53.2.0/24')- Store Gateway-A's intended remote selector.
- What you should see
- Expect no error; assignments are silent and send no packets.
- Why this step matters
- Parsed membership tests avoid confusing textual similarity with correct prefix matching.
Record the baseline matrix
At the same Python terminal console, test the two intended hosts and one unrelated destination. Read True or False as membership only, not a permit verdict from a VPN gateway.
print(a in local, b in remote)
print(ip_address('10.53.3.10') in remote)
print(b in remote and a in local)What each command means
print(a in local, b in remote)- Check both intended endpoint memberships.
print(ip_address('10.53.3.10') in remote)- Check that an unrelated network is outside the remote selector.
print(b in remote and a in local)- Evaluate the reversed endpoint roles against the corresponding ranges.
- What you should see
- Expect True True, then False, then True. These are predicted model values, not captured traffic.
- Why this step matters
- The negative case makes an accidentally overbroad selector visible alongside the intended positive case.
Label the tunnel headers
At the Python prompt in the VM terminal console, create two explicit pairs. Print their names so the peer addresses cannot be mistaken for the application's final addresses.
inner = (str(a), str(b))
outer = ('192.0.2.1', '198.51.100.1')
print('inner:', inner, 'outer:', outer)What each command means
inner = (str(a), str(b))- Represent the original host source and destination as text.
outer = ('192.0.2.1', '198.51.100.1')- Represent the security-gateway WAN pair.
print('inner:', inner, 'outer:', outer)- Display labeled pairs; no encapsulation or encryption occurs.
- What you should see
- Expect the two different address pairs with their labels intact.
- Why this step matters
- The label exercise is useful precisely because it does not pretend that a tuple is an encrypted packet.
Introduce one bounded selector fault
In the same Python terminal console, change only the remote prefix from /24 to /25. Do not change either host, the local prefix or any real network setting.
remote = ip_network('10.53.2.0/25')
print(a in local, b in remote)
print(remote.network_address, remote.broadcast_address)What each command means
remote = ip_network('10.53.2.0/25')- Simulate a remote selector that includes only .0 through .127.
print(a in local, b in remote)- Repeat the same membership checks with the changed prefix.
print(remote.network_address, remote.broadcast_address)- Display the modeled range boundaries to explain the failure.
- What you should see
- Expect True False and range .0 through .127; Host-B .200 is excluded.
- Why this step matters
- A single changed variable links the unexpected decision to a specific reproducible cause.
Restore and retest both cases
At the same Python terminal console, restore the documented /24 and repeat the positive, negative and reverse-role checks. Do not stop after merely reassigning the variable.
remote = ip_network('10.53.2.0/24')
print(a in local and b in remote)
print(ip_address('10.53.3.10') in remote)
print(b in remote and a in local)What each command means
remote = ip_network('10.53.2.0/24')- Restore the original selector exactly.
print(a in local and b in remote)- Retest the intended forward membership pair.
print(ip_address('10.53.3.10') in remote)- Retest exclusion of the unrelated network.
print(b in remote and a in local)- Retest the reverse-role pair without claiming a reverse SA.
- What you should see
- Expect True, False, True after restoration; retain your actual model transcript.
- Why this step matters
- A repaired positive result without the negative check could conceal a wider policy error.
Close without claiming a tunnel
At the Python prompt in the VM terminal console, exit the interpreter. In your notes separate the observed membership results from untested VPN requirements: algorithms, identities, SAs, counters, routing and application access.
exit()What each command means
exit()- End the disposable interpreter session and discard its in-memory worksheet variables.
- What you should see
- Expect return to the shell; no Cisco configuration, network interface or credential was changed.
- Why this step matters
- The completed evidence is an offline reasoning exercise, not successful IPsec deployment.
Verify
- Record the interpreter version or explicitly label the worksheet hand-traced.
- Preserve baseline True/False cases and the exact /25 fault without substituting real gateway output.
- Confirm inner host addresses and outer gateway addresses are labeled separately.
- After restoration, verify intended membership, unrelated exclusion and reverse-role membership.
- For any later live lab, require independent SA, selector, counter and application evidence; none is supplied here.
Troubleshoot
- If Python reports NameError, stay in the same interpreter and repeat the variable-definition step before retesting.
- If .200 appears to fit /25, inspect the prefix start and end; the lower /25 ends at .127.
- If the live VPN status is green but a flow fails, do not use this worksheet as proof of tunnel operation; collect the actual peer evidence.
- If an alternative simulator lacks cryptographic support, keep the exercise conceptual rather than inventing a successful SA.
GNS3 does not provide Cisco images. A license or entitlement must permit the image in the selected environment; do not share or redistribute image files. Cisco Modeling Labs is an official alternative. Its supplied Cisco reference images are licensed for use within CML, not automatically for export to GNS3. An unlicensed learner must use the explicitly labeled paper alternative, not report simulated Cisco execution.
- Exit the interpreter and leave the VM disconnected.
- Keep synthetic notes only; no real secret, key or certificate belongs in the worksheet.
- For any separately authorized hardware exercise, follow its own rollback procedure; this model changed no hardware.
Practice set
Answer before you reveal
01Which addresses are inside this tunnel-mode packet?
The gateway WAN pair belongs to the new outer header. Encapsulation does not change the application's intended server.
02Does AH hide the application payload?
Do not infer encryption from the word IPsec. The chosen protocol and negotiated services determine protection.
03Why are two IPsec SAs normally needed?
The negotiation relationship is distinct from the directional data-protection state used by each peer.
04Is ESP TCP port 50?
Transport ports and IP protocol numbers occupy different fields. NAT traversal can wrap ESP in UDP.
05Why does .200 fail the faulty selector?
Restoring /24 changes membership. It does not by itself prove peer authentication or protected delivery.
06What remains unproved by the Python worksheet?
Only address membership and labels were exercised. Report that scope even if every model value matches expectations.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Name original endpoints separately from VPN peers.
- Distinguish IKE negotiation from directional IPsec traffic protection.
- ESP and AH supply different services; AH is not encryption.
- Tunnel and transport modes differ in packet structure.
- A VPN is a protected path with policy, not universal trust.
- Model results and live cryptographic evidence must never be conflated.