The GreenBow VPN client using PSK (11.x)

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

The GreenBow VPN client using PSK (11.x)

Post by jono » 13 May 2008, 14:40

This How-to applies to:
  • Clavister CorePlus 11.x
    The GreenBow VPN Client
Topics covered in this document
  • Security Gateway
  • Pre-Shared Key
  • Configuring proposal lists and SA lifetimes
  • VPN Tunnel properties
  • Routing
  • Policy Section

    GreenBow Client
  • Setting up the IP addresses of the client
  • Identification and certificates
  • IKE Parameters
  • Proposals
  • Troubleshooting
Pre-Shared Key
The first thing you need to do is to create a shared secret. This is commonly referred to as PSK (pre-shared key). This is done in Key Ring section in the Objects folder.
IPsec-Psk.png (30.04 KiB) Viewed 1908 times
Pick a name for your PSK, this can be anything you please and has nothing to do with the actual authentication between client and gateway.

VPN Tunnel properties
This is actually a lot easier than it might seem at the first glance. Only a few things need to be known in order to setup the possibility for roaming clients to connect to protected networks through IPsec VPN. First you add a new IPsec tunnel in the VPN and Tunnel section located in the Network folder of the Security Gateway.

First of all, you need to decide on a name to assign to the virtual interface that the configured VPN connection will use. We will use this virtual interface later on.

In this example, the name IPsec_tunnel is being used.
IPsec-General.png (51.06 KiB) Viewed 1908 times
Encapsulation Mode
Here we choose Tunnel mode since we're using pure IPsec.

Local Network
This is the local network that the roaming users will connect to. However, this is only the first level of access gratification. Without the proper rules in place under the Rules section, this itself does not mean that the roaming user can connect to the internal network.

Remote Network
The Security Gateway looks at this field and compares it to the roaming user's source IP address in order to allow connections only from the configured local net to remote net. However, in this scenario, clients should be allowed to roam in from everywhere. Thus, this field is set to all-nets ( That means that virtually all existing IPv4-addresses are allowed to connect.

Local Endpoint
This is the local address all remote users will connect to, i.e WAN_ip.

Source Interface
Here we choose any since we want to be able to connect from all interfaces.

Remote Endpoint
Basically, this field is only used when setting up a Lan-to-Lan VPN. The Remote Endpoint is the address of the machine where all the packets that are originating from the Local network travelling towards Remote net will be sent, in order to be processed by the IPsec engine

Note The remote endpoint none is used in roaming client scenarios. The Security Gateway will send its reply to the IP address that initiated the IKE/IPsec connection instead of a certain gateway. That makes it the obvious choice for roaming clients.

IKE Algorithms
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.

Furthermore, authentication method (pre-shared key, two different public key systems or digital signature) and Diffie-Hellman group is negotiated through IKE.

IPSec Algorithms
The IPsec Algorithms, very simplified, a list of algorithms defining how to encrypt the data that is sent through the IPsec tunnel.
Note in the IPsec Lifetime you need a value of at least 2700 seconds to match the IPsec lifetime proposal sent by the Greenbow Client.

As authentication method, choose Pre-Shared Key. Then, in the Pre-Shared Key drop-down list, select the Pre-Shared Key you created previously in the Pre Shared Key section.
IPsec-auth.png (13.16 KiB) Viewed 1908 times

IPsec-IKE.png (58.14 KiB) Viewed 1908 times
IKE (mode)
When configuring the gateway, IKE mode is not important. It only applies when its configured on the initiator, and the gateway is always the responder in a scenario like this. The difference between "IKE Main mode" and "IKE Aggressive mode" can be summarized into: "Aggressive mode means more data in less packets".

DH (Diffie-Hellman) group however, is important. In this scenario, it can be left at the default which is modp group 2 (1024 bit). DH group can best be explained as a method for secure exchange of encryption keys. It does this by first creating a "shared secret", between the two devices. The shared secret is then used to create the symmetric key for secure transmittal.

This has nothing to do with PSK.

Perfect Forward Secrecy
Perfect forward secrecy, commonly known as PFS, is a term which means that the compromise of an IKE phase 1 key does not cause the compromise of further sessions, because of the re-keying. The nice thing about this is that it does not require a repetition of authentication that is already taken care of.
Note in this scenario we leave this as default, None(no PFS), 2(1024), 5(1536) and 1(768). Remember to set the same value in the Greenbow Client.

Security Association
There are three possible choices here. From a perspective of roaming clients, it is important that the SA Per Net option is selected.

NAT Traversal There are three settings.
  • Off, means that the Security Gateway will not tell the client that it supports NAT Traversal.
  • On if supported and NATed. In this setting the Security Gateway will tell the client that it supports NAT T, but if the Security Gateway had been the initiatior won't propose NAT T to be used if not necesairy. In this case the client is the initiatior and the Clavister will accept what the client proposes.
  • On if supported. Normally this setting would cause the Security Gateway to propose NAT T regardless if the incoming IKE packet is NATed or not. Like in the On if supported and NATed, it will accept any proposal that the client makes.
Automatic Route Creation
This is preset as Add route statically, you want to change this to Add route dynamically. This setting is found under the Advanced tab in the IPsec tunnel.
Dynamic-route.png (10.64 KiB) Viewed 1908 times
Policy Section
First thing to think about, is that in the Clavister Security Gateway ruleset, lookup begins at the top of the ruleset, and will take action at the first matching rule.
IPsec-Policy.png (36.81 KiB) Viewed 1908 times
In the configuration above, the policy that allows the roaming clients to connect to the internal network has been inserted as the first policy.

For roaming clients, the most common action types are Allow or NAT. NAT is especially applicable if the roaming users should be able to access a network/computer that does not have the VPN gateway as its default gateway. If address translation is not used in such a case, the replies would be sent wrong due to the routing.

The Service of the policy should reflect the type of network traffic that should be allowed from the clients. For this scenario we will use all-servies.

The VPN gateway configuration should now be completed.

TheGreenBow VPN client
GreenBow-Phase1.png (52.48 KiB) Viewed 1908 times
Setting up the IP addresses of the client
GreenBow-Tunnel-Params.png (23.6 KiB) Viewed 1908 times
First we need to define the related information in the VPN client. The IP address of the Clavister Security Gateway. The PSK passphrase we created earlier in the guide. As well as the private IP address of the remote network.
GreenBow-Phase1-Settings.png (59.33 KiB) Viewed 1908 times
Next is IKE here you need to select which encryption algorithms that should be used when establishing the tunnel as well as the DH group. You will need to match your selected algorithms with those you chose in the Clavister Security Gateway.

Note: To change name on you VPN tunnel, right click and select Rename.

GreenBow-Phase2-Settings.png (62.89 KiB) Viewed 1908 times
Here we specify the settings associated with Phase-2.

VPN Client address Virtual IP address used by the client inside the remote LAN: The computer will appear in the LAN with this IP address. In this scenario we want to give the client the IP address when the tunnel is established.

Address type The remote endpoint may be a Network, a single computer or an IP range. In our scenario the Remote LAN is

Last is the ESP and PFS sections which determines which encryption algorithms we want to use in Phase-2. Here in phase 2 we also want to select the settings matching the Clavister Security Gateway.

To connect using the GreenBow Client, double click the phase 2 tunnel.
GreenBow-To-Connect.png (61.56 KiB) Viewed 1908 times
It should look like this when connected:
GreenBow-Connected.png (62.45 KiB) Viewed 1908 times

If something goes wrong and the VPN tunnel is not properly established, there are a few things that should be checked:
  • First of all, check that the IP address of the remote gateway is what it should be (your Clavister Security Gateway). Also check that the remote net on the client is correct.
  • Verify that lifetimes/algorithms on gateway and client match. Note: If you have not changed any lifetimes or encryption algorithms you can skip this part.
  • Make sure that you don't have two Roaming Clients configurations under VPN Tunnels section: One with PSK and another one with certificates, that won't work.

Posts: 41
Joined: 24 Oct 2016, 08:23

Re: The GreenBow VPN client using PSK (11.x)

Post by mape » 31 Oct 2016, 16:15

Updated 2016-10-31

Post Reply