VPN Routing between offices via HQ (10.x)

Security Gateway Articles and How to's
Locked
Peter
Posts: 652
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

VPN Routing between offices via HQ (10.x)

Post by Peter » 24 Apr 2008, 14:32

This How-to applies to:
  • Clavister CorePlus 8.x, 9.x
  • Clavister cOS Core 10.x
Problem:
I have one Central HQ node and (at least) 2 remote offices. I already have the remote offices connected to the Central node using IPsec tunnels, but I want the two remote offices to be able to communicate with each other by using the existing IPsec tunnel(s) towards the Central HQ node (hub-and-spoke setup). I don't want to setup tunnels between all remote offices (full mesh setup) as that quickly increases the number of tunnels as the number of offices increase (n*(n-1) tunnels for n offices)!
VPN_HQ_Offices2.jpg
VPN_HQ_Offices2.jpg (22.82 KiB) Viewed 3365 times
Object list:
[list]HQ-Net - 10.10.0.0/24
OfficeA-Net - 192.168.1.0/24
OfficeB-Net - 192.168.2.0/24
OfficeA-GW - 1.2.3.4
OfficeB-GW - 2.3.4.5
CentralHQ-GW - 3.4.5.6
[/list]
The current Ipsec tunnel configuration on the Central-HQ node is the following:

Name Local-Network Remote-Network Remote-Gateway
VPNOffice-A HQNet OfficeA-Net OfficeA-GW
VPNOffice-B HQ-Net OfficeB-Net OfficeB-GW
This works fine when Central-HQ wants to talk to Office-A and when Central-HQ wants to talk to Office-B and vise versa. But if Office-A wants to talk to Office-B it wont work since A. We do not have a route and B. We do not have the office networks defined on the Ipsec tunnels.

We need to modify all Ipsec tunnels to take into account that there is more than one network behind the Central-HQ Ipsec tunnel. In order to accomplish this we make some network groups to be used for this, so in addition to the previous object list we add the following:
[list]OfficeA-Group which consists of 2 networks. 10.10.0.0/24 and 192.168.1.0/24
OfficeB-Group which consists of 2 networks. 10.10.0.0/24 and 192.168.2.0/24[/list]
Now we need to modify all the Ipsec tunnels to take into account the new networks.

On the Central-HQ node:

Name Local-Network Remote-Network Remote-Gateway
VPNOffice-A OfficeB-Group OfficeA-Net OfficeA-GW
VPNOffice-B OfficeA-Group OfficeB-Net OfficeB-GW
On Office-A:
VPNHQ OfficeA-Net OfficeB-Group CentralHQ-GW
On Office-B:
VPNHQ OfficeB-Net OfficeA-Group CentralHQ-GW
If we examine the above changes we see that what we have done is to expand the "local network" on the Central HQ node to include the Office-A and B networks depending on which tunnel that establishes. When the Office-A tunnel establishes we also allow them to send queries to/from the 192.168.2.0/24 network thru the tunnel. Don't forget to modify/add the corresponding route(s) on the Ipsec interface.

Example:

The Ipsec route on Office-A currently look like this:
Route VPNHQ HQ-Net
We can simply modify this route to use the group we created and used as the remote network, it will then look like this:
Route VPNHQ OfficeB-Group
Troubleshooting:
Depending on the problem you have various ways to diagnose what the problem could be, the most common problems are with Rules, Routes and the Ipsec tunnel establishment.

If the problem is with Rules and/or routes you can use the Ping Simulations to troubleshoot any routing problems, a more detailed description of Ping Simulation can be found here: viewtopic.php?f=8&t=3401
If the problem is with the tunnel establishment, the best "tool" to use is the console command "ikesnoop -on -verbose". For more information about ikesnoop please see the Clavister Admin Guide. "Troubleshooting with Ikesnoop".

Locked