A Security Association (SA) must be created on the Ecessa device before VPN connectivity can be established. An SA provides parameters that the VPN will use to establish a connection and provide additional information necessary for endpoints to communicate. Commonly an SA will establish endpoint IP’s, available subnets accessed via the tunnel, and authentication credentials.
To create an SA navigate to the ‘Configure VPN’ page. Select the ‘Enable VPN’ check box and click the activate button located at the bottom of the page. When the page reloads click the ‘Add SSL’ button to create an SA.
Ecessa Configuration
Each of the three Ecessa configuration types have common parameters that must be configured: an SA name, local addressing, remote addressing, and a PKCS12 certificate. The rest of this section describes these parameters while connection type specific parameters are discussed in their corresponding sections.
The SA name is straightforward and should be chosen to help aid in identifying the usage of the VPN. For example, ‘RemoteAccess’, would be appropriate for a server configuration that provides remote access to clients. If it is a Point-to-Point connection, naming the SA with the corresponding site might make identification easier.
Local addressing is supplied under the section ‘Local Information’. These parameters pertain to the Ecessa device that is currently being configured. If WAN addresses are left blank, the default behavior is to listen on all interface addresses found on the ‘Configure WAN’ page on port 1194. If port 1194 is not desired simply add a local WAN with the WAN address left blank and change the port to the port number that the server should listen on. The Ecessa device will still listen on all available WAN interface IP’s. To listen only on a specific line or lines completely fill out the local WAN portion with WAN addresses and ports for each interface.
Also under ‘Local Information’ is the LAN Networks parameter which identifies the local subnets available to connecting devices. This information is given in CIDR or slash notation. For example to push the subnet 192.168.1.0 with a subnet mask of 255.255.255.0 to connecting devices the local LAN configuration would be 192.168.1.0/24.
Remote addressing is entered under the section ‘Remote Information’ on the SA configuration page. Remote addresses are the IP’s and ports that the VPN can connect to. LAN networks are subnets available on the other side of the connection. The server type connection does not allow these parameters to be configured.
The certificate chosen for authentication is a PKCS12 file that has been uploaded to the Ecessa device or created on the Ecessa device on the Certificates page. This certificate must have an export password of at least 5 characters and be signed by the same CA that signed all other certificates that will be used in authentication.
It is important to note that only one SA using multiple IP addresses can use a single port; reusing the same IP with another port in a different SA is allowed.
Server
To begin the creation of a server SA select ‘Server’ from the ‘Connection Type’ dropdown menu. A server SA requires the following information at a minimum:
- An SA name
- Local addressing
- A PKCS12 certificate
- A Server IP Pool for tunnel addressing
The required section, ‘Server Settings’ is not covered under ‘Ecessa Configuration’. You will define the ‘Server Pool IP Range’ in CIDR notation. This IP range is used to address the tunneling adapter used in the VPN connection. When traffic from remote clients reaches the local subnet it will be addressed with an IP from this range. For example, to use the private class C address space of 192.168.253.0, the value 192.168.253.0/24 would be entered. Clients will be dynamically addressed from this available pool.
Additional options for the SA are ‘Protocol’, ‘DNS’, ‘WINS’, and ‘Search Domain’. The protocol used by default is UDP. This is a connectionless protocol with less overhead than TCP. Because the traffic encapsulated in the VPN will usually have its own mechanisms for reliable data transfer it is best to leave this as UDP. WINS might be needed for pre-Windows 2000 name resolution that happens outside of DNS (NetBIOS).
DNS server information can be pushed to a client if it is preferable for a client to use an internal DNS server for name resolution. This will facilitate access of internal resources by hostname that would not be available on an external domain. Supplement to this is a ‘Search Domain’ that will be used in DNS resolution. This removes the need to enter a fully qualified domain name (FQDN) to access internal resources.
Below is an example configuration listing how the fields and values could be populated. This is an SSL Server VPN SA named Remote Access. The server will listen on all available WAN interface IP’s (found under ‘Configure WAN’) on port 1195. The class C subnet of 192.168.50.0/24 will be made available to connecting clients. Additionally, the client, upon connecting, will set the DNS servers to 192.168.50.251 and 192.168.50.252 with a search domain of ‘mydomain.com.’ This server uses the UDP protocol to encapsulate traffic, compresses the traffic immediately and automatically starts and listens for incoming connections.
Once all required fields are filled out click the ‘Activate’ button located at the bottom of the page. This will redirect back to the ‘VPN Configuration’ page. From here an entry for the new SA will appear. The status column should be yellow and show ‘Running.’ Once a client is connected the certificates common name will appear in the ‘Remote Addresses’ column and the ‘Status’ column will change to a green ‘UP.’ See the section ‘Client Configuration’ for details and for setting up clients.
Point-to-Point
A Point-to-Point connection is configured at two sites, both with Ecessa devices. One site will have the role of Point-to-Point server and the other site will be a Point-to-Point client. The following information is required to successfully configure a Point-to-Point connection:
- An SA name
- VPN private tunnel addresses for both sites
- Local addressing
- Remote addressing
- A PKCS12 certificate
When configuring a point-to-point connection both sites should essentially be mirrored images, swapping the ‘Local Information’ and ‘Remote Information’ fields. The following figure is an example of two sites: Site A and Site B.
In this example Site A will be the point-to-point server and Site B will be the point-to-point client. Each site has one local LAN subnet that will be made available to the other site. Additionally each of the sites two WAN lines will be used to provide VPN redundancy and failover.
Site A, the point-to-point server, will be configured first. We have determined that the IP’s available are 173.160.5.10 and 65.5.189.246 on port 1195. This information was obtained by reviewing both the ‘View Inbound’ tab and the ‘One-to-One NAT’ rules that are selected to allow inbound. The important aspect is that the address and port desired are not being passed through the device. Before beginning the configuration at Site A, Site B’s endpoint addresses must be determined. Use the steps that were used to determine available addresses at Site A. In this example 12.31.20.23 and 61.6.53.5 are available on port 1194 at Site B.
- Begin the configuration by navigating to ‘Configure VPN’ and clicking the button ‘Add SSL’.
- The SA name will be called Site B to reference where the VPN terminates.
- Choose ‘Point-to-Point’ from the Connection Type drop-down.
- Enter ‘Local Information’
- VPN Endpoint is 192.168.250.2
- Add both local WAN’s 173.160.5.10 and 65.5.189.246 with port 1195
- Add the Local LAN 192.168.70.0/24
- Enter ‘Remote Information’
- Enter the VPN Endpoint 192.168.250.3
- Add remote Addresses 12.31.20.23 and 61.6.53.5 with port 1194
- Add the remote LAN 192.168.71.0/24
- Select Certificate from the Authentication Type drop-down.
- Select the appropriate PKCS12 certificate from the drop-down.
- Check Auto Start and Point-to-Point Server.
- Click the ‘Activate’ button located at the bottom of the page.
Next, configure Site B, remember that this configuration is essentially the mirror image of Site A (see the below diagram for an example). The important difference is that Site B’s configuration does not have Point-to-Point Server selected under ‘Optional Settings’ at the bottom of the page.
The final step is to configure static routes on the client side (Site B). The simplest way to create the necessary static routes is through the use of load balanced host records (LHR). Define a new domain on the Ecessa device called ‘static.route’ (domain creation is done in ‘Authoritative DNS’). Configure the domain with two simple host records ‘sslvpn1’ and ‘sslvpn2’ matching to the IP’s 12.31.20.23 and 61.6.53.5. Then create a ‘Load balanced’ record called ‘sslvpn’ and select the simple host records ‘sslvpn1’ and ‘sslvpn2’ in the ‘Canonicals (Name/IP)’ section. Finally, check ‘Redundancy Only’. The top entry will be the preferred line; reordering is possible by clicking on the entry number under ‘Simple Host Records’.
Next, create ‘Static Routes’ with the following settings. Use the LBR as the source WAN IP or Hostname. Set the destination network to as a /32 or host netmask for each of the VPN endpoints. The type should be set to ‘Failback’ from the drop-down menu.
Returning to the ‘Configure VPN’ page the ‘Status’ column should now display a green ‘UP’ indicator.
0 Comments