Configuring split tunneling using the Shrewsoft VPN client

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

Configuring split tunneling using the Shrewsoft VPN client

Post by Peter » 03 Jul 2015, 14:43

This How-to applies to:
  • Clavister Security Gateway version 10.x and up.
    Shrewsoft VPN client 2.2.2 and up.
Description:

This article will describe how to configure the Shrewsoft VPN client towards a Clavister Security Gateway using Pre-Shared key and manually configured split-tunneling with automatically assigned IP address using CFG Mode.

Note: Currently it is not possible to automatically hand out the network to the client as the Shewsoft client does not understand the "INTERNAL_IP4_SUBNET" Cfg Mode attribute Clavister is sending (may be subject to change in the future).

Configuring the Clavister, objects needed

Before we start configuring the tunnel we create the following objects:

1. A group of two internal networks (in this example the group consists of 80.80.80.0/24 and 90.90.90.0/24) called G2_G3_Net_Grp.
2. A network object called CFG_Mode_Pool_Net (192.168.60.0/24.
3. A Keyring->PSK for use on the IPsec tunnel called Shew_PSK
4. Objects->IKE Config Mode Pool where we define a static IP pool to be 192.168.60.240-192.168.60.250. We do not use the entire /24 network but it can easily be extended in the future depending on the number of users involved. We also specify a DNS.

Configuring the IPsec tunnel in the Clavister:

To configure the IPsec tunnel we apply our previously created objects as shown in the below picture.
Shrew_Guide_1.png
Shrew_Guide_1.png (38.13 KiB) Viewed 6298 times
The local network (1) we use the group we created that consists of our two example internal network 80.80.80.0/24 and 90.90.90.0/24. These are the two internal networks we want our client users to be able to access.

For the remote network (2) we use the CFG_Mode_Pool_Net object previously created, this object is a /24 network even though we are only using 10 addresses in the pool currently. It is a pre-caution for the future, we can extend the pool without having to change the networks on the IPsec tunnel. It also has a big advantage to specify which IP the client should use when accessing resources beyond the tunnel, that way we do not have to use "all-nets" as the remote network. The more we can restrict and limit access the better, we also avoid situations where a client is incorrectly configured with a network that conflicts with the internal networks behind the Clavister.

Remote Endpoint (3) is set to be all-nets, as we do not know from which IP our roaming clients are connecting from we must allow everything.

Encapsulation mode (4) we will leave at the default Tunnel mode. Since we want to communicate with entire networks we cannot use transport mode.

For IKE Config Mode Pool (5) we select the CFG_Mode_Pool object we created earlier (it is always called Static).

Lastly for the IKE (6) and IPsec (7)algorithms we leave them at their default values. This will be configured to match in the client later, needless to say the algorithm we want to use in this case is AES specifically and that algorithm is part of the default "High" proposal list for both IKE and IPsec.

For Authentication we chose Pre-shared key and the PSK we created earlier.
Shrew_Guide_2.png
Shrew_Guide_2.png (3.75 KiB) Viewed 6298 times
For the IKE settings tab we leave everything at their default values. Which is IKE DH group 2, PFS DH Group None, 01, 02 and 05. Security Association is Per Net, NAT-T is "On if supported and NATed" and Dead PEer Detection is set enabled.

Now we need to make sure that under the Advanced tab that "Add Route Dynamically" is enabled and "Add route Statically" is disabled. This means that we only want a route to be created for the IP address the VPN client got from the CFG Mode pool once the client is connected. Without this route it would not be possible to receive any traffic from the IPsec tunnel. (Note: If you encounter this problem it would be shown as "Default_Access_Rule" in the logs).
Shrew_Guide_3.png
Shrew_Guide_3.png (3.79 KiB) Viewed 6298 times
Once the IPsec tunnel is created we are now one step away from configuring the client, the last thing we need is an IP rule or policy that allows traffic from the newly created IPsec interface to the internal networks in question.
Shrew_Guide_4.png
Shrew_Guide_4.png (5.88 KiB) Viewed 6298 times
This is of course a very generous example IP rule, as an administrator you may want to restrict this rule a bit more to only allow the ports and protocols that should be used and/or restrict the target networks to be specific machines instead of entire networks.

Configuring the ShewSoft VPN client

This article will not discuss any problems related to client installation, it will assume that the Shrewsoft VPN client is correctly installed.

Start the VPN Access Manager and press Add to create a new profile.
Shrew_Guide_5.png
Shrew_Guide_5.png (13.86 KiB) Viewed 6297 times
First we input the host name or IP address (1) of the Clavister public IP (or in this case an internal test IP)

Next we need to specify that the client should "pull" Config Mode information from the server (2).

As "Local Host" we select "Use a virtual adapter and assigned address" (3) as we want to he client to use the IP address i receives by the Clavisters Config Mode Pool. We also need to enable the "Obtain Automatically" option (4).

For the client Tab we do not change anything, we leave all values here at their default.
Shrew_Guide_6.png
Shrew_Guide_6.png (9.89 KiB) Viewed 6297 times
For the name resolution tab we enable DNS and enable the options to Obtain both DNS and DNS suffix automatically. The information we specified on the CFG Mode Pool in the Clavister will be sent to the client using this setting.
Shrew_Guide_7.png
Shrew_Guide_7.png (8.38 KiB) Viewed 6296 times
The authentication tab contains identity information sent by the client to the server (Clavister), we will use ID type IP address and let the client automatically discover a host address.
Shrew_Guide_8.png
Shrew_Guide_8.png (10.15 KiB) Viewed 6296 times
The Credentials sub-tab (1) is important as here you must input the Pre-shared key you created in the Clavister earlier.

The Phase-1 tab contains the proposal (IKE) parameters sent by the client, it is not recommended to use auto as the client sends a huge list of proposals to the remote endpoint. Instead we have manually chosen to use only ciphers, exchange groups, key-lengths etc that is compatible with the "High" proposal list in the Clavister as shown in the below picture.
Shrew_Guide_9.png
Shrew_Guide_9.png (9.74 KiB) Viewed 6296 times
The same goes for Phase-2 (IPsec) as shown in the picture.
Shrew_Guide_10.png
Shrew_Guide_10.png (9.25 KiB) Viewed 6296 times
Last but not least we come to the Policy tab. Here we tell the VPN client what kind of network(s) that it should tunnel towards the remote endpoint. First we Change from Auto to "Unique" (1), this means that the client will negotiate a unique IPsec SA for each Policy.

And lastly we add (2) the two networks we defined on the Clavister as the "Local Network". So our two internal networks as shown in the picture.
Shrew_Guide_11.png
Shrew_Guide_11.png (11.48 KiB) Viewed 6296 times
It might also be a good idea to enable "Maintain persistent SA", this means that when the tunnel establishes, it will negotiate all network combinations. Without the option it will only establish the first network and then the second if/when something wants to access that particular network.

In case of problems, your best "tool" to use is the "ikesnoop -on -verbose <ip>" in the CLI, for more help about troubleshooting IPsec tunnels please see the following How-To Article: viewtopic.php?f=8&t=3699

IKESnoop example:

Sometimes it can be a great advantage to have access to an ikesnoop showing a successful negotiation using the configuration described in an article such as this, such an ikesnoop can be downloaded from here :
Ikesnoop_Shrewsoft.zip
(2.11 KiB) Downloaded 247 times

Post Reply