Natting - Over - Site To Site VPN
Natting - Over - Site To Site VPN
Natting - Over - Site To Site VPN
Scenario
Consider the following network wherein both the Head Office (HO) LAN and the Branch Office (BO)
LAN have the same internal IP schema.
Network Parameters
Local Server (WAN IP address) 192.168.20.105
HO Network details Local LAN address 172.16.16.0/24
Local NATted Address 172.16.15.0/24
VPN server (WAN IP address) 192.168.20.191
BO Network details LAN Network 172.16.16.0/24
NATted Address 172.16.17.0/24
As a result, the VPN endpoints fail to differentiate between own network and remote network. Any
request initiated from HO destined for BO would be served within HO itself and vice versa. For
example, a host from HO initiates a request to host 172.16.16.10 in BO, but it is responded by Host
172.16.16.10 in the HO itself because the endpoint cannot differentiate between HO LAN and BO
LAN.
As a solution to this, Cyberoam provides NATting over VPN which allows Cyberoam to assign Dummy
LAN IP address (NATted LAN) to differentiate between LANs at both ends. This article describes how
you can configure an IPSec Connection using NATted LANs.
How To Apply NAT over Site-to-Site VPN connection
HO Configuration
The configuration is to be done from HO Cyberoam Web Admin Console using profile having read-
write administrative rights for relevant feature(s).
Parameter Description
Local PortB-192.168.20.105 Select local port which acts as end-point to the tunnel
BO Configuration
The configuration is to be done from BO Cyberoam Web Admin Console using profile having read-
write administrative rights for relevant feature(s).
Parameter Description
The above configuration establishes an IPSec connection between the HO and BO.
Note:
Make sure that Firewall Rules that allow LAN to VPN and VPN to LAN traffic are configured.
In a Head Office and Branch Office setup, usually the Branch Office acts as the tunnel initiator
and Head Office acts as a responder due to following reasons:
Since Branch Office or other Remote Sites have dynamic IPs, Head Office is not able to
initiate the connection.
As there can be many Branch Offices, to reduce the load on Head Office it is a good practice
that Branch Offices retries the connection instead of the Head Office retrying all the branch
office connections.