- Clavister cOS Core Security Gateway 11.x
Two Clavister cOS Core Security Gateways
One Clavister cOS Core Security Gateway and another type of VPN terminator.
Topics covered in this document
- Prepare the Address Book
- Create a Pre-Shared Key
- Create custom IKE and IPsec Proposal lists (optional!)
- Create the IPsec Tunnel
- IP Policies
Prepare the Address Book
The first thing to do is to add all objects needed by the IPsec tunnel. The remote network and the remote gateway.
When this is done, you should have two new objects in the address book. Remember that you need to do the respective configurations on your second gateway.
NOTE:All these addresses are examples, you should use the IP addresses that are used in your network.
Remote_net = 192.168.40.0/24
Remote_endpoint = 172.16.12.2
Remote_net = 192.168.30.0/24
Remote_endpoint = 172.16.12.1
It should look something like this: Create a Pre-Shared Key
To be able to authenticate the IPsec tunnel that will be used, a pre-shared key needs to be defined. A pre-shared key can either a passphrase or a randomly generated Hexadecimal key. This is done under Objects > Key Ring > Add Pre-Shared Keys.
NOTE: You need to define the same PSK on the second gateway. In this Guide we will use a psk called: IPsec_psk.
Create custom IKE and IPsec Proposal lists (optional!) This optional step is needed if you either want to use specific encryption and integrity algorithms, or if the other end uses specific settings that you must match and the predefined proposal lists (Medium and High) does not work.
In this how-to we will create new algorithms for our IPsec tunnel.
Create two proposal lists, one for IKE and one for IPsec. Select SHA1 and AES as algorithms and name them accordingly.
This is done under Objects > VPN Objects > IKE/IPsec Algorithms section:
Create the IPsec Tunnel Now it's time to set up the IPsec tunnel, this is done in the IPsec Tunnels section located in the Network tab of the Security Gateway. The example screenshot above shows the Clavister Security Gateway
First of all, a name is needed for the VPN connection.
In this example, the name Lan-Lan is being used.
Here we select IKEv1.
As we're setting up a lan-lan tunnel this should be set to Tunnel Mode.
This is the local network that the remote users will connect to and the local users connect from.
Usually this is "lan_net" or similar. It can also be a collection (group) of networks or ranges, or just a single IP. It can also be "all nets".
The important thing is that this matches what is specified as "remote network" for the other Security Gateway.
We will use the Lan_net.
NOTE1: This is the so called "remote_net" of the second gateway.
NOTE2: If the clients are roaming, "all-nets" has to be used, since we don't know were they are coming from.
This is the network that the remote users will connect from or our local users connect to.
Here we select our earlier created "remote_net" object.
NOTE: If the clients are roaming, "all-nets" has to be used, since we don't know were they are coming from.
This is the IPv4 Address of the Security Gateway where the tunnel will be terminated.
In this guide we select our created "Remote_endpoint"
Authentication Authentication Method
Here we select our previously created PSK, IPsec_psk.
IKE(Phase-1) Diffie-Hellman group
Here we can leave the default value of 02(1024), simply remember to select the same DH-group on your second gateway.
Here we select the IKE algorithm we have determined to use with the other Security Gateway. Either use the predefined Medium or High, which contains several different algorithms and key lengths, but that will give you less control over the encryption methods used, so in this example we will use the specified algorithm we created earlier (AES, SHA1).
We leave the life-time to it's default value.
We choose Main Mode and not aggressive mode since we want the connection establishment to be encrypted.
Outgoing Routing Table
We select the routing table main.
Here we select our DMZ_ip.
NOTE:This IP is the Remote_endpoint of the second gateway. Remember this interface IP is simply an example, you should of course use the interface and ip corresponding to your network.
Incoming Interface Filter
This is an optional setting used with virtual routing scenarios, so we will use the standard any.
Here we leave all settings to their default value.
IPsec(Phase-2) PFS (Perfect Forward Secrecy)
We leave the default values.
Select the IPsec algorithm we created earlier and leave the life-time settings to there default.
Setup SA Per
Under the routing section under advanced make sure that you have Add Route Statically selected.
NOTE: If we're using a roaming IPsec Tunnel, set the Add route dynamically setting and Disable the Add Route Statically.
When doing a two-way tunnel, two IP Rules are needed. One IP Policy to allow traffic coming from the remote network to the local network.One IP Policy to allow traffic to go from the local network through the tunnel to the remote network. If you want to limit to a single direction, or that only a specific IP, e.g. a web server, or port/protocol should be allowed, you can adjust your IP Rules accordingly.
Action is Allow, Source Interface is Lan, Source Network is Lan_net, the Destination Interface is Lan-Lan, the Destination Network is Remote_net and Service is All_Services (We might want to use a different Service to limit the allowed traffic).
Action is Allow, Source Interface is Lan-Lan, Source Network is Remote_net, the Destination Interface is Lan, the Destination Network is Lan_net and Service is All_Services (We might want to use a different Service to limit the allowed traffic).
When done with the IP Policies it will look something like this: NOTE:Remember to do matching settings on the other Security Gateway.
For trouble shooting, we recommend that you connect to the CLI and use the "ikesnoop -on -verbose" command to see the tunnel negotiation. Since Keep Alive was not activated in this example, an easy method to establish the tunnel is to ping any host address in the remote_net. The response itself is not the primary goal here, just to start up the tunnel, so it does not matter if a host is there or not.
You can also ping simulate incoming and outgoing traffic, to verify your IP Rules and routing:
Assuming 192.168.40.0/24 is the remote_net and 192.168.30.0/24 is Lan_net. Again, neither host need to actually be there and respond, although it is more fun if they do, the goal is to verify the route and IP Rules used
ping 192.168.40.5 -srcif=lan -srcip=192.168.30.2 -verbose
ping 192.168.30.2 -srcif=Lan-Lan -srcip=192.168.40.5 -verbose