The purpose of this document is to provide an understanding of IPSEC Site-to-Site VPN functionality on the Ecessa appliance and how it should be configured to connect to a remote WatchGuard device.
Through the use of an example network, this article will highlight various options commonly used when configuring the VPN feature of Ecessa products.
Below is a diagram illustrating the example network used for our example. The goal is to connect the Ecessa LAN to the remote network's LAN via an IPSEC VPN tunnel.
Click on “VPN” under “Advanced Setup” in the menu of the web interface.
To create a new VPN Security Association, click the Add IPsec button.
The Ecessa™ VPN Security Association Configuration
This page allows you to add/edit a Security Association and contains 4 main sections-
Local & Remote Info
The top section of the page contains the basic information for the Security Association. This section contains the following fields:
- The Name field contains the name of the Security Association. If you are editing an existing SA then you will not be able to change the name. If you are adding a new SA then choose a unique descriptive name up to 24 characters long (alpha-numeric and hyphens). The name is arbitrary and only used locally, so both sides do not need to be similar.
- Minneapolis is chosen as the Security Association.
The local WAN address from both WAN’s and the local network are entered below.
- The WAN IP/WAN Alias/FQDN field has to contain either an IP address on a configured WAN interface, a configured WAN alias, or a Fully Qualified Domain Name (FQDN) resolvable by DNS to one or more WAN IP addresses. This defines the local end of the VPN connection. If an IP address is entered that is within one of your WAN subnets, and the address does not already exist, then the address will be added as a secondary IP address on the WAN port.
- The LAN Subnet field is an optional field which can contain a LAN network (given in xxx.xxx.xxx.xxx/MASK format – e.g. 192.168.10.0/24). This defines the local LAN subnet to which remote peers will have access. Both sides must agree on this parameter.
The remote addresses for the firewall in Minneapolis are entered below.
- The FQDN/IP address field is an optional field which can contain the remote VPN peer address or a FQDN. If left blank, then this defines a server-only configuration which will allow any remote address to connect (known as a road-warrior).
- The LAN Subnet field is an optional field which can contain a LAN network (given in xxx.xxx.xxx.xxx/MASK format – e.g. 192.168.10.0/24). This defines the remote LAN subnet to which the local system will have access.
The IKE Authentication Type chosen below is PRE-SHARED Secret. As a result a shared secret is chosen as “Secret”. These same settings will have to be entered on the firewall in Minneapolis.
The Security section of the page contains fields which specify the different options that you can choose for security.
- The IKE Authentication Type specifies the authentication method that you wish to use for this SA. Both sides must be in agreement. Here are the options available in the drop-down menu:
- Pre-Shared Secret - a secret passphrase is used, which must be known by both local and remote administrators. If you select this method then you must enter the secret in the Shared Secret field.
- The Shared Secret should contain a passphrase that both the local and the remote administrators must know. This field should only be filled in if the Pre-Shared Secret option is chosen in the IKE Authentication Type field. The remote side must be configured with the exact same secret.
“ANY” is chosen for all encryption and authentication options below. This allows for flexibility when negotiating with the other side.
The Encryption section of the page contains fields which specify the different cryptographic options that you can choose for the Security Association. Choosing Any in the drop-down menus for these parameters will allow flexibility in negotiating with the other side which types will be used for the connection. Specifying particular options, on the other hand, will allow only the selected cryptographic types to be used.
- The Phase 1 Encryption field is used to select the cryptographic cipher algorithms that are allowed in Phase 1 of the Internet Key Exchange (IKE). IKE Phase 1 consists of authenticating the peers and setting up a secure channel for subsequent key exchange. If you do not care which encryption algorithm is used, then the default Any value will allow negotiation with the remote peer to determine the type. Otherwise, the 3DES or AES values can be selected to only allow those particular cipher algorithms to be used.
- The Phase 1 Authentication field is used to select the cryptographic hash functions used for authentication during IKE phase 1. The default value of Any will allow negotiation with the remote peer to determine the hash function. Otherwise, the SHA1 or MD5 hash functions can be selected with either the ESP Encapsulating Security Protocol or the AH Authentication Header protocol.
- The Phase 2 Encryption field is used to select the cryptographic cipher algorithms that are allowed in Phase 2 of the Internet Key Exchange (IKE). IKE Phase 2 consists of secure negotiation of Security Association parameters and setting up the IPsec tunnel. If you are not concerned which encryption algorithm is used, then the default Any value will allow negotiation with the remote peer to determine the type. Otherwise, the 3DES or AES values can be selected to only allow those particular cipher algorithms to be used.
- The Phase 2 Authentication field is used to select the cryptographic hash functions used for authentication during IKE phase 2. The default value of Any will allow negotiation with the remote peer to determine the hash function. Otherwise, the SHA1 or MD5 hash functions can be selected with either the ESP Encapsulating Security Protocol or the AH Authentication Header protocol.
- The IKE Group field is used to select the Diffie-Hellman prime-modulus group used during the Main Mode of the IKE. The possible values are Any to allow any group, Group 2 to select the 1024 bit group, orGroup 5 to select the most secure 1536 bit group.
Error Recovery Options
Enable Failover testing is selected by default. Enable Failback is selected so that if a failure occurs, VPN traffic will go to back over the preferred path as soon as it comes back up.
The Error Recovery Options allow you to Enable/Disable Failover Testing and other error recovery features for a Security Association. By default, testing is enabled. However, if the remote side will not respond to an ICMP Echo (Ping) it is recommended that the Failover Testing be disabled, or the Manual IP Configuration option be used.
Note: Only one side of the VPN should have Failover Testing enabled.
- The Enable Failover Testing check box, if checked, will cause the Ecessa™ to periodically test the IP Test Point configured below.
- The Test Point Type select box determines whether to use the Remote Endpoint of the SA or to manually configure the method used for testing. When Remote Endpoint is selected, the Ecessa™ selects the test point using the following criteria:
- If the remote endpoint is configured as a FQDN, the Ecessa™ uses the IP address resolved when the SA is established.
- If the remote endpoint is configured as a single IP, the Ecessa™ uses that IP Address for testing.
- The Number of Tests to Perform field contains the number of test attempts to perform during a test. The SA is considered to be up if at least one attempt succeeds.
- The Enable Failback check box, if selected, enables the VPN connection to fail back to a preferred path after a failover has occurred. Select this option if the Security Association is configured with multiple local or remote endpoint addresses and there is one set of endpoints that is the preferred path. In that case when the connection fails on the preferred path and fails over to another path, and the preferred path subsequently becomes operational again, the connection will be restored back on the preferred path. Enter the Local WAN Addresses and Remote Addresses to the list in order of preference.
The Other Options that are on the bottom section of the page contain options that might be selected in some circumstances.
- The Auto Start checkbox, if checked, will cause the connection defined by this Security Association to start as soon as the Submit button is clicked on the bottom of this page. The connection will also start automatically when VPN is first enabled on the Ecessa, and after rebooting the Ecessa, This option can only be selected if a Remote FQDN/IP Address has been specified (i.e. it is not a road-warrior server-only type of SA). This option will not work if the XAuth Client is selected.
- The No Proxy checkbox, if checked, will prevent this VPN traffic from the LAN from being proxied by the Ecessa™. This should be checked if a service, such as VoIP for example, would otherwise proxy this traffic and cause it to not be sent out the VPN tunnel.
Once you are done entering all necessary fields for the Security Association, press the Submit button to apply the changes.
Start the VPN
Select the VPN and click Start.
For our example, the remote Watchguard has already been configured so the VPN updates with an UP status.
Avoiding Conflicting Security Associations
Be careful not to create Security Associations that will conflict with existing Security Associations. The following scenarios should be avoided:
- Two or more SA’s using the same local and remote IP addresses
- Two or more SA’s using the same local and remote LAN subnets
*For additional details, please visit the help pages located within the web interface of the device.
Configuring the Watchguard
Note that VPN Failover can occur only if:
- Firebox must have Fireware v10 or higher installed.
- Multi-WAN failover is configured,.
- The interface(s) of your Firebox are listed as gateway pairs on the remote Ecessa.
Define multiple gateway pairs
If multi-WAN is configured and managed tunnels are created, WSM automatically sets up gateway pairs that include the external interfaces of both ends of the tunnel. No other configuration is necessary.
To configure manual BOVPN tunnels to fail over to a backup endpoint, more than one set of local and remote endpoints (gateway pairs) for each gateway must be defined. For complete failover functionality for a VPN configuration, define gateway pairs for each combination of external interfaces on each side of the tunnel. For example, suppose the local endpoint is 10.60.0.18/29 and the primary remote endpoint is 172.20.1.58/29 with a backup of 10.50.0.18/29. For complete VPN Failover, these gateway pairs need to be defined:
10.60.0.18 - 172.20.1.58
10.60.0.18 - 10.50.0.18
- Select VPN > Branch Office Gateways. Click Add to add a new gateway. Give the gateway a name and define the credential method.
- In the Gateway Endpoints section of the New Gateway dialog box, click Add. The New Gateway Endpoints Settings dialog box appears.
- Specify the location of the local and remote gateways. Select the external interface name that matches the local gateway IP address or domain name you add. Both a gateway IP address and gateway ID for the remote gateway can be added. This may be necessary if the remote gateway is behind a NAT device and requires more information to authenticate to the network behind the NAT device.
- Click OK to close the New Gateway Endpoints Settings dialog box. The New Gateway dialog box appears. The gateway pair defined appears in the list of gateway endpoints.
- Repeat this procedure to define additional gateway pairs (up to nine gateway pairs can be added). To re-order the list, select a pair and then select the Up or Down key to change the order in which the Firebox attempts connections.
- Click OK.