Information Security 11 min read

Configuring an IPSec Site‑to‑Site VPN Between Headquarters and Branch NAT Devices

This guide demonstrates how to configure routers, firewalls, NAT, and IPSec policies to establish a site‑to‑site VPN between a headquarters and branch office when both use NAT devices, enabling mutual access and internet connectivity.

Practical DevOps Architecture
Practical DevOps Architecture
Practical DevOps Architecture
Configuring an IPSec Site‑to‑Site VPN Between Headquarters and Branch NAT Devices

This experiment shows how to set up an IPSec tunnel between a headquarters and a branch office when both sites use NAT devices as their export gateways, allowing mutual communication and internet access.

1. Router configuration (routing between FW1 and FW2)

interface GigabitEthernet0/0/0 ip address 220.163.100.1 255.255.255.0 # interface GigabitEthernet0/0/1 ip address 220.163.200.1 255.255.255.0 #

2. FW1 configuration

a) Interface IP addresses

interface GigabitEthernet0/0/0 ip address 192.168.10.1 255.255.255.0 # interface GigabitEthernet0/0/1 ip address 220.163.100.2 255.255.255.0

b) Assign interfaces to zones

firewall zone trust add interface GigabitEthernet0/0/0 # firewall zone untrust add interface GigabitEthernet0/0/1

c) Enable inter‑zone packet filtering (permit all for the lab)

firewall packet-filter default permit all

d) Static default route

ip route-static 0.0.0.0 0.0.0.0 220.163.100.1

e) Define protected traffic

acl number 3000 rule 5 permit ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255

f) IPSec proposal “tran1”

ipsec proposal tran1 esp authentication-algorithm sha1 esp encryption-algorithm aes

g) IKE proposal “10”

ike proposal 10 authentication-method pre-share authentication-algorithm sha1

h) IKE peer configuration

ike peer c pre-shared-key 123456 ike-proposal 10 remote-address 220.163.200.2

i) IPSec policy map1

ipsec policy map1 10 isakmp security acl 3000 ike-peer c proposal tran1

j) Apply IPSec policy to the external interface

interface GigabitEthernet0/0/1 ip address 220.163.100.2 255.255.255.0 ipsec policy map1

k) NAT policy (exclude IPSec‑protected flow, then source‑nat the rest)

nat-policy interzone trust untrust outbound policy 1 action no-nat policy source 192.168.10.0 0.0.0.255 policy destination 192.168.20.0 0.0.0.255 policy 2 action source-nat easy-ip GigabitEthernet0/0/1

3. FW2 configuration (mirrors FW1 with opposite subnets)

a) Interface IP addresses

interface GigabitEthernet0/0/0 ip address 192.168.20.1 255.255.255.0 # interface GigabitEthernet0/0/1 ip address 220.163.200.2 255.255.255.0

b) Zones, packet filter, static route, ACL, IPSec/IKE proposals, IKE peer, IPSec policy, and NAT are configured analogously to FW1, using the 192.168.20.0/24 network and the opposite public IPs (220.163.200.1/2).

4. Verification

On FW1 and FW2 the IKE SA tables show two tunnels (IDs 1 and 40001) in READY state. The IPSec SA tables display tunnel mode “map1”, correct local/remote tunnel IPs, and matching inbound/outbound ESP SAs. Ping tests from PCs in both subnets succeed with 0 % packet loss, confirming end‑to‑end connectivity.

firewallNATnetwork configurationVPNIPSec
Practical DevOps Architecture
Written by

Practical DevOps Architecture

Hands‑on DevOps operations using Docker, K8s, Jenkins, and Ansible—empowering ops professionals to grow together through sharing, discussion, knowledge consolidation, and continuous improvement.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.