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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

NATNetwork 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

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.