TheGreenBow VPN client to Clavister Firewall with PSK (Pre-Shared Key)
This Knowledge Base article applies to:
Clavister Security Gateway version 8.50, 8.60
SisTech TheGreenBow VPN
|
This document should not be considered a definitive guide to connecting TheGreenBow VPN client to a Clavister firewall. Rather, it should be treated as what it actually is; A quick guide to setting up a encrypted connection between above mentioned products. It does not discuss the various ways one could go about to achieve this; nor does it discuss the possible implications on security different configurations might produce.
This document assumes that you already got a firewall up and running. If not, please consult the proper documentation for this.
Topics covered in this document
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 Pre-Shared Keys section in the VPN Settings folder.
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 VPN tunnel in the VPN Tunnel section located in the Interface folder of the firewall.
Name
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 both the Routes and Rules section.
In this example, the name RoamingVPN is being used.
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 firewall 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 (0.0.0.0/0). That means that virtually all existing IPv4-addresses are allowed to connect.
Remote Gateway
Basically, this field is only used when setting up a Lan-to-Lan VPN. Remote gateway is the machine where all the packets originating from Local net travelling to Remote net will be sent, in order to be processed by the IPsec engine.
The remote gateway none is used in roaming client scenarios. The firewall 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 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.
Furthermore, authentication method (pre-shared key, two different public key systems or digital signature) and Diffie-Hellman group is negotiated through IKE.
Enable IKE Config Mode ( Version 8.60+ )
When Config mode is enabled the clients connecting will automaticly recive an IP address, DNS server, WINS server etc. that is defined under Local Objects->VPN Settings->ConfigMode Pool.
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.
Authentication
|
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.
Per default the Clavister sends it's external IP as Local ID type, here you have the option to select a specific IP, DNS or E-Mail as ID.
|
|
IKE
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.
Note: 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 a 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.
Security Association
As you can see, there are two possible choices here. From a perspective of roaming clients, it is important that the SA Per Host option is selected.
Compatibility Flags
Don't Verify Padding is more of a "backwards compatibility"-option. Some older IPsec implementations has a erroneous way to insert the padding in the packets that sometimes can make things fail.
NAT Traversal There are three settings.
- Off, means that the firewall will not tell the client that it supports
NAT Traversal.
- On if supported and NATed. In this setting the firewall will tell the client that it supports NAT T, but
if the firewall 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 firewall 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.
VPN Tunnels and routing
I versions prior to the 8.50 of the clavister firewall, the return packets automatically was
returned to the correct VPN tunnel. In this versions, due to the virtual routing, you must add a
route to the VPN tunnel in order to send the return packets back to tunnel. This is usually easiest
done by checking the Dynamically add route in the Routing tab.
Manual routing
If the IP of the VPN client is known and you need to proxy ARP that IP, you could add the IP
directly in the Routes section. The reason for the proxy ARP is when the client send a packet to
a server on the internal network and has an IP of that network itself, that server will make an
ARP query for the clients IP. If the clavister answers to that ARP query, it will also receive
the IP packet from the server and could send that back to the client on the other side of the
tunnel.
 
Rules Section
First thing to think about, is that in the Clavister Firewall ruleset, lookup begins at the top of the ruleset, and will take action at the first matching rule.
In the configuration above, the rule that allows the roaming clients to connect to the internal network has been inserted as the first rule.
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.
Service
The Service of the rule should reflect the type of network traffic that should be allowed from the clients. For instance, if Terminal Services are allowed, the service type should be set to TCP and destination port to 3389.
This however is a bit out of scope for this section.
The VPN gateway configuration should now be completed.
TheGreenBow VPN client
Setting up the IP addresses of the client
First select Configuration and right-click to create a new Phase-1
First we need to define the name and related information in the VPN client.
Name The name of Phase 1 ( authentication )
Interface The IP adress from which to connect, in this scenario the client is using DHCP so we select * to enable the use of any IP address the client recives.
Remote Gateway The IP address of the Clavister Security Gateway.
In this scenario we will use a Preshared Key, type in your chosen key and confirm it on the second row.
Next is IKE here you can select which encryption algorithms that should be used when establishing the tunnel. The default IKE and IPSec
roaming client proposal lists of Clavister is fully compatible with the default settings of TheGreenBow VPN client, no change is needed in the
proposal lists.
Note: That may be a subject to change in future versions, but current version of TheGreenBow is fully compatible. ( V 2.51.008 )
Phase-2
Setting up Phase-2
Next is Phase 2 of the configuration, first we select our previously created OfficeVPN, Right-Click then select Add Phase 2.
|
Here we specify the settings associated with Phase-2.
Name. Label for IPSec Configuration only used by the VPN client. This parameter is never transmitted during IPSec Negotiation
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 10.10.10.50 when the tunnel is establised.
Address type. The remote endpoint may be a LAN or a single computer. In our scenario the Remote LAN is 10.0.0.0/8 which corresponds to the Remote LAN Address of 10.0.0.0 with a Subnet Mask of 255.0.0.0.
Last is the ESP and PFS sections which determines which encryption algorithms we want to use in Phase-2. With the use of the default roaming client proposal list on the Clavister there is no need to change these settings. Click Save & Apply and open the tunnel by either clicking Open Tunnel or send traffic thru the tunnel which will start the VPN tunnel automaticly.
Troubleshooting
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 Firewall). 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 a DNS server is specified correctly under Advanced settings on the firewall and that the default gateway is set under the section Routes.
- Make sure that a you donīt have two Roaming Clients configurations under VPN Tunnels section: One with PSK and another one with certificates, that wont work.
|
Published: 2007-01-17 13:27:55 (GMT +01:00)
|
|
Copyright Đ Clavister AB
|
Legal
|
|
