|
 |
Lan To Lan VPN Tunnels with Pre-Shared Key and Routing
This Knowledge Base article applies to:
Clavister Firewall 8.20 and newer
|
This document assumes that you already got the two firewalls up and running and in the same datasource. If not, please consult the proper documentation for this.
Topics covered in this document
Preparing the Host & Networks
|
The first thing to do is to move all relevant host and network information from each of the two firewalls that will in the tunnel to the global namespace. This is done by first checking out the Global Namespace then go to each firewall and move the relevant hosts and networks to the Global Namespace. To move an item, make that item active, and use the Edit->Move to namespace... or by using Move to namespace... from the context menu. The items you should move is ip_ext and intnet from each of the firewalls.
|
|
|
When this is done, you should have four new objects in the Host & Networks under Global Namespace, these will have been renamed with the original name prepended with the name of the firewall, and should look something like this:
Preparing VPN Settings
|
After the hostname is moved, a Pre-Shared Key, or Shared Secret need to be created for use with the tunnel, this is PSK should be created in the Global Namespace so it can be accessed by both firewalls.
In the Pre-Shared Key section just use Ctrl-N or File->New Pre-Shared Key to create a new PSK. This will show a dialog as the one on the right, give the PSK a name that gives a hint of what it's for, in this case StockholmHelsingforsPSK is used. When running Lan-to-lan we can use a Hexadecimal Key and this is easiest created by using the Generate Random Key... button.
|
|
|
Setting up the VPN Tunnels
|
Now it's time to setup the VPN Tunnels, this is done in the VPN Tunnels section located in the Interface folder of each firewall. The example screenshot on the right shows the Stockholm firewall.
Name
First of all, a name is need that the VPN connection will use. This virtual interface will be used later on, in both the Access and Rules section.
In this example, the name HelsingforsVPN is being used in the Stockholm firewall, and StockholmVPN in the Helsingfors firewall.
Local Network
This is the local network that the remote users will connect to. So in the Stockholm firewall Stockholm_intnet will be used and in the Helsingfors firewall Helsingfors_intnet.
Remote Network
This is the network that the remote users will connect from. So in the Stockholm firewall Helsingfors_intnet will be used and in the Helsingfors firewall Stockholm_intnet.
Remote Gateway
This is the public ip's of each firewall, where the tunnels will be terminated. So as before the Stockholm firewall will use Helsingfors_ip_ext and the Helsingfors firewall will use Stockholm_ip_ext.
|
|
|
IKE Proposal List
IKE (Internet Key Exchange) is used to create IPsec security
associations (SAs). An IKE SA is basically something that (in the VPN
gateway) identifies the IPsec session and associates it with a protocol
(ESP or AH), keys and algorithms. In the howto the pre-defined proposal list ike-lantolan will be used.
IPSec Proposal List
The IPsec proposal list is, very simplified, a list of proposals
defining how to encrypt the data that is sent through the IPsec
tunnel. In the howto the pre-defined proposal list esp-tn-lantolan will be used.
Authentication
In the Authentication tab as authentication method, choose Pre-Shared Key. Then, in the Pre-Shared Key drop-down list, select the Pre-Shared Key created previously in the Pre-Shared Key section, StockholmHelsingforsPSK.
Setting up the Route
|
Starting from version 8.20, you can route VPN, and therefore there is no need for adding anything to Access. So what is needed is adding a new route in the Routes section located in the Routing folder of each firewall.
To do this, press Ctrl-N or choose File->New Route... and add a new Route row to the firewall, this route should be the remote network of the tunnel coming trough that VPN interface, so in the Stockholm firewall Helsingfors_intnet will be routed trough the HelsingforsVPN VPN tunnel. Of course it will be the other way around in the Helsingfors firewall.
|
|
|
Setting up the Rules
When the routes part is done, all that is left is the rules, when doing a two-way tunnel there is two rules needed. One rule to allow traffic coming from the remote end of the tunnel and one rule allowing traffic to go out trough the tunnel to the remote side.
First the rule for outgoing traffic, this rule should allow traffic coming from the internal network on the int-interface to go to the network behind the remote gateway.
So in the Stockholm firewall a rule is added with the following characteristics, Action is Allow, Source Interface is int, Source Network is Stockholm_intnet, the Destination Interface is HelsingforsVPN as we are no longer using Secure, the Destionation Network is Helsingfors_intnet and finaly the Service is All.
The second rule needed is for incoming traffic, this rule allows traffic coming in from the remote network on the vpn-interface.
In the Stockholm firewall a rule is added with the following characteristics, Action is Allow, Source Interface is HelsingforsVPN, Source Network is Helsingfors_intnet, the Destination Interface is any, the Destionation Network is Stockholm_intnet and finaly the Service is All. The reason for using Any for Destination Interface is to be able to ping the internal ip of the gateway trough the tunnel, if Int was used it would not be possible to ping the ip of the firewall, as it is routed on the <core> interface.
It is of course possible to use a pre-defined service as rdp or similiar instead of All.
This will be duplicated in the Helsingfors firewall, but of course the other way around. When all these changes are done, check-in the Global Namespace and Deploy the configurations, to test the tunnel, ping the internal ip of the remote gateway from a host on the internal network.
The firewall configuartions used in this howto can be downloaded from here: Example Datasource
|
