Project: secure branch office with site-to-site VPN

Goal and requirements

The goal is the classic small-business brief: a branch office must reach file and print services at head office (HQ) securely over the internet, without leased lines. You will use IPsec (Internet Protocol Security) with IKEv2 (Internet Key Exchange version 2), the current standard for site-to-site tunnels.

• Functional: branch hosts reach HQ servers; both sites keep local internet access.
• Security: strong, modern crypto; only the two LANs are allowed through the tunnel; management access by SSH only.
• Resilience (stretch goal): a second tunnel or dynamic routing so that failover can be shown.
• Tools: GNS3, EVE-NG or Cisco Modeling Labs with IOS-XE or IOSv images, or two pfSense/OPNsense VMs. Packet Tracer supports only older IKEv1 crypto maps, which is acceptable for a first version.

Design

Use documentation address ranges for the "internet" so nothing in your lab looks like a real network. A route-based VPN with a virtual tunnel interface (VTI) is easier to troubleshoot than a policy-based crypto map, because the tunnel behaves like any other interface and you can route over it.

Build plan

1. Build the underlay: both edge routers plus an "ISP" router; check each edge can ping the other's WAN address.
2. Add basic security to every device: hostnames, SSH, local users, banners, NTP.
3. Configure IKEv2 and the tunnel on HQ (below), then mirror it on the branch with the addresses swapped.
4. Route the remote LAN over Tunnel0, and add NAT overload on each WAN interface for local internet access. Tunnel traffic is routed into Tunnel0 before NAT on the outside interface, so it keeps its private addresses inside the encrypted packets.
5. Apply an inbound ACL on each WAN interface that allows only IKE (UDP 500 and 4500), ESP and what you need for management.
6. Test, capture evidence, then try the stretch goals.

crypto ikev2 proposal PROP-LAB
 encryption aes-cbc-256
 integrity sha256
 group 19
crypto ikev2 policy POL-LAB
 proposal PROP-LAB
crypto ikev2 keyring KR-LAB
 peer BRANCH
  address 203.0.113.2
  pre-shared-key <long-random-key>
crypto ikev2 profile PROF-LAB
 match identity remote address 203.0.113.2 255.255.255.255
 identity local address 198.51.100.1
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-LAB
crypto ipsec transform-set TS-LAB esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile IPSEC-LAB
 set transform-set TS-LAB
 set ikev2-profile PROF-LAB
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.2
 tunnel protection ipsec profile IPSEC-LAB
ip route 192.168.20.0 255.255.255.0 Tunnel0

show crypto ikev2 sa
show crypto ipsec sa
show interface tunnel 0
ping 192.168.20.1 source 192.168.10.1

The tunnel is working when the IKEv2 security association (SA) shows READY, the IPsec encrypt and decrypt counters rise while you ping between LANs, and a packet capture on the ISP link shows only ESP packets, never the inner ICMP. See IPsec explained if the phases are unfamiliar.

Deliverables and how to present it

• A design document: requirements, topology diagram, IP plan and crypto choices with reasons.
• Sanitised configurations (remove keys and passwords) in a Git repository.
• A test plan with results: tunnel up, LAN-to-LAN reachability, ESP-only capture, failover if built.
• A short troubleshooting log, such as a mismatched proposal and how you found it.

On a CV: "Designed and built a route-based IKEv2 site-to-site VPN between two sites in EVE-NG, with WAN ACLs and verified ESP-only traffic." In an interview, be ready to explain why you chose a VTI, what DH group 19 is, and how you would add certificates instead of a pre-shared key.