|
 |
VPN Client 1.4 to Clavister Firewall 8.0 with PSK (Pre-Shared Key)
This Knowledge Base article applies to:
Clavister VPN Client 1.4
|
This document should not be considered a definitive guide to connecting a Clavister 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. When using the Clavister VPN client, only passphrase is applicable.
|
|
Configuring proposal lists and SA lifetimes
First of all, it should not be necessary to add to or modify the proposal lists. There are pre-configured proposal lists that match the ones in the VPN client. However, if you feel that you need to add/modify them for some reason, you can do that by opening the VPN Settings in the Global Namespace with the Security Editor. Make sure that any changes you do to lifetimes/algorithms are applied to the VPN client configuration as well.
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 Access 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.
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.
|
|
Flags
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
Connection Keep-alive makes sure that re-keying is done even if no data has gone through the tunnels in the time period that the SA lifetimes define.
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.
Access Section
IKE (mode)
Starting from version 8.0, the firewall first consults the routing table to determine if the sender address of incoming packets are permitted. This means that for most configurations not using VPN, the Access configuration section can be left empty. For firewalls using VPN, Access configuration items need to be defined to accept incoming traffic from VPN tunnels.
This is fairly simple, only accept traffic from all addresses heard on the VPN interface. This, again, is because the clients should be able to roam in from anywhere.
The reason for using Accept instead of Expect is that if Expect would be used here, all other nets on any interface would have been dropped, because they would be expected to come through the VPN interface.
|
|
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.
Clavister VPN client
Installation of the VPN client
One of the few things to think about during the installation of the VPN Client is to choose Administrator e-mail as primary host identifier if you plan to use self-signed certificates later on as authentication key. VPN connections. This is normally the step right after generating the random seed. Its not critical if you by mistake choose something else, its changeable later, on a per configured connection basis.
Key Management
Because we need to configure a PSK to use for authentication against the VPN gateway, this is the normally the first step. This is done by running the Policy Editor, clicking on Key Management and choosing Add under My Keys.
Security Policy
Pre-IPSec Filter
This is actually a set of rules that are active when the client is in state "IPSec enabled". They dictate what kind of traffic that is supposed to be allowed outside of the tunnel. The default is very generous, for instance, DNS is allowed outside of the tunnel, which might lead to problems if you want your Windows 2000 workstation to lookup other Windows 2000 or Windows XP hosts using the internal DNS server.
The solution here is to either change the rule so it drops all DNS requests sent in the clear, or configuring the search order for DNS in Windows, and then allow DNS traffic to the ISP:s DNS servers, and make sure all other DNS goes in the tunnel. This way, its possible to make your computer use several DNS servers, and it will use the latter one configured (depending on search order) to resolve hosts that the first one failed with.
VPN Connections
|
As can be seen from the screen shot to the right, this is a pretty straightforward configuration if everything is configured correctly in the VPN gateway.
Gateway IP address
Specify the IP address of the external interface of the VPN gateway.
Remote network
This is where the internal network behind the VPN gateway is defined. This should be identical to the Local Network specified in the VPN Tunnel configuration.
Authentication key
Choose the PSK created with the Key Management tool in the VPN Client.
NAT Traversal
As from version 8.10 we supports NAT Traversal in the Firewall, and if your client has a NATed connection to the Internet you must enable NAT-traversal in the VPN client.
To do this select your VPN connection and pick Properties and Advanced. Enable the setting Pass NAT devices using.
|
|
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.
- If you are using NAT-traversal, running Diagnostic of the VPN connection will sometimes fail, but you can still establish the tunnel by "right-click" on the VPN icon and pick your tunnel under Select VPN.
- 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.
- Make sure Accept and not Expect is chosen as action in the Access section of the gateway configuration.
|
