(This document refers to the 10.7.2 firmware version's updated VPN layout and settings)
The purpose of this document is to provide an understanding of IPSEC Site-to-Site VPN functionality on the Ecessa device. Through the use of an example network, this will highlight various options commonly used when configuring the VPN feature of Ecessa products. Below is an example network used throughout the rest of the documentation. Our goal here is to connect the Ecessa LAN to the remote networks LAN via an IPSEC VPN tunnel.
Click on VPN under “Advanced Setup” in the left-hand menu.
Confirm the VPN feature is enabled and then click the Add IPSec button.
Ecessa™ VPN Security Association Configuration - Basic Configuration
This page edits a Security Association and contains six sections under the Basic tab and an additional four sections under the Advanced Tab.
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 Connection Type dropdown allows you to select the type of VPN that you would like to create. In this example, "Site to Site" will be selected.
Local & Remote Information
The local WAN address from both WANs and the local network are entered below.
- The WAN Address 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 Network 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 Remote 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 Network 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.
In the Shared Secret field, you will enter the shared secret for this IPSEC VPN. These same settings will have to be entered on the firewall in Minneapolis.
The Shared Secret will contain a passphrase that both the local and the remote administrators must know. 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 for establishing 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 the ESP Encapsulating Security Protocol.
- The IKE Group field is used to select the Diffie-Hellman prime-modulus group used during the Main Mode of the IKE.
- 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, AES, BLOWFISH, or TWOFISH 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, SHA2, or MD5 hash functions can be selected with the ESP Encapsulating Security Protocol.
- The Lifetime field is used to set the Phase 2 Lifetime of this VPN. This parameter determines how long the VPN will stay up before needing to rekey. This value is always entered in seconds. The default is 3600 seconds.
- The Rekey setting determines if the device should initiate rekey tasks. It is enabled by default.
Dead Peer Detection Options
The Dead Peer Detection Options and Error Recovery Options (Advanced page, see below) allow the device to monitor the tunnel status and recover if it is down. Dead Peer Detection relies on keep-alive messages and should be used if the remote device will not respond to pings.
- Dead Peer Restart will try to re-initiate a connection if no response is received but does not trigger a failover in the event a WAN is down. For this reason it is only recommended to use Dead Peer Restart if there is only a single local and single remote WAN in the VPN configuration.
- Dead Peer Clear will clear a connection if no response is received. It will not attempt to re-initiate the connection. This should be used for a road-warrior VPNs (where no Remote Addresses are configured) or for VPN failover in the event a WAN is down. VPN failover with Dead Peer Clear is only possible in certain cases with the On Demand start option (please see the article: VPN On Demand (10.7.2+) for more details).
If Dead Peer Restart or Dead Peer Clear are selected it is possible to modify the following keep-alive testing parameters (these cannot be used with IKEv2):
- DPD Test Timeout - determines the waiting period for a keep-alive response from the remote. Value is in seconds.
- DPD Number of Tests - determines the number of keep-alive packets to send. If no response is received by the end of all the tests, the action defined in Dead Peer Detection Mode will be performed.
For further details on Dead Peer Detection, please see the help box near the title of the section.
The Active/Passive testing (described further below) can also be used for VPN failover if the remote end responds to pings. However, if the remote side will not respond to an ICMP Echo (ping), it is recommended that either Dead Peer Detection or the Manual IP Configuration Test Point Type is used.
The Start Option defines what action the Ecessa device should take when starting the VPN (enabling the VPN feature, enabling the VPN SA, clicking Activate on the VPN SA page, or on device boot up).
- Disabled - the Ecessa device will listen for any incoming connection attempts from the remote VPN peer to build the tunnel but will never initiate a VPN connection
- Auto Start - the Ecessa device will immediately try to initiate a connection with the remote VPN peer upon starting the VPN. This option can only be selected if a Remote Address has been specified
- On Demand - the Ecessa device will listen for any "interesting" (VPN LAN-to-LAN) traffic and during this time the VPN will be in a RUNNING state. It will automatically initiate a connection to the remote VPN peer if interesting traffic is seen after which the VPN will be in the UP state.
Ecessa™ VPN Security Association Configuration - Advanced Configuration
Access the "Advanced Configuration" page by clicking the "Advanced" tab near the top of the screen. This section provides additional options for more advanced configurations.
One-to-One NAT Rules
The One-to-One NAT Rules section can be used to define rules which will create a mapping between LAN IP addresses and arbitrary NAT IP addresses. This can be useful in cases where the remote end may have VPN connections to multiple sites which have the same LAN Subnet(s). Or in cases where the remote end itself may have the same LAN Subnet as this Ecessa device. In the latter case the remote end should also have One-to-One NAT rules.
For further details on VPN One-to-One NAT rules, please see the help box near the title of the section.
Error Recovery Options
Failover testing is disabled by default. If Failover testing is enabled (Active or Passive), then Enable Failback can be selected so that if a failure occurs, VPN traffic will go to back over the preferred path as soon as it comes back up. 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.
Note: Only one side of the VPN should have "Active" Failover Testing enabled. The other side should be "Passive."
The Test Point Type select box determines whether to use the Remote Endpoint of the Security Association or manually configure the remote host and method used for testing.
- When Remote Endpoint is selected, the Ecessa device 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.
- When Manual IP Configuration is selected, the Ecessa device tests through the tunnel to a host on the remote LAN. The remote LAN host to ping is defined by the Test IP field.
- Protocol - selects the protocol to be used for testing (TCP or ICMP). ICMP is used by default. TCP can be used if the remote host reachable at the Test IP does not respond to pings.
- TCP Port - if TCP is the Protocol in use, defines which port to test the remote host. The remote host must respond to TCP SYN packets sent to the designated port.
- Time Out - defines the waiting period for a response. Value is in seconds.
- The Number of Tests to Perform contains the number of test attempts to perform. The SA is considered to be up if at least one attempt succeeds.
The Other Options that are on the bottom section of the page contain options that might be selected in some circumstances.
- 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. This is enabled by default.
For further details on the other options available in this section, please see the help box near the title of the section.
Once all necessary fields for the Security Association are configured, press the Activate button to apply and save the changes.
Start the VPN
If necessary, select the VPN and click Start. If the remote end is configured and online, the VPN connection will come up.
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.