vpnipsec - Manage IPsec VPN tunnels and networks
[1] vpnipsec [authenticate [psk (<pre-shared-key> | auto) | (tls | eaptls) <tls-id> [(dn | fqdn)]]]
[2] vpnipsec [access [(off | on) [<ike-encryption [<ike-integrity> [<ike-diffie-hellman> [<esp-encryption> [<esp-integrity>]]]]]]]
[3] vpnipsec [access [conf (android | apple | linux | windows) (<client-tls-id> | any) (show | save (ftp | sftp | tftp) <file-server> <file-path> | email <email-address>) [<name>]]]
[4] vpnipsec [access [authenticate [(psk | tls | eaptls)]]]
[5] vpnipsec [access [access [raz | (add | del) <ike-id>]]]
[6] vpnipsec [site [add <vpn-id> <peer-vpn-address> (psk <pre-shared-key> | tls (certificate <tls-id> | dn ’<distinguished-name>’ | fqdn <domain-name>)) [<ike-encryption] [<ike-integrity> [<diffie-hellman> [<esp-encryption> [<esp-integrity> [<remote-isakmp-port> [<remote-nat-transversal-port>]]]]]]]]]
[7] vpnipsec [site [raz | del <vpn-id>]]
[8] vpnipsec [network [(access | site <vpn-id>) [(raz | ((add | del) (local | remote) <network-ip> [<network-mask>]))]]]
[9] vpnipsec [via [(access | site <vpn-id>) [raz | (add | del) <gateway-ip> (master backup) [<priority>]]]]
[10] vpnipsec [to [<vpn-id> [raz | (add | del) <peer-vpn-address>]]]
[11] vpnipsec [nat (public [raz | (add | del) <local-public-ip>]) | (role [<vpn-id> [(active | passive | raz)]])]
[12] vpnipsec [report]
VPN stands for Virtual Private Network and IPsec for Internet Protocol Security. An IPsec VPN allows you to authenticate and encrypt the data packets between private networks over a public IP network (ie internet) to provide secure encrypted communications. You can build a persistent IPsec VPN between 2 sites or allow remote workers to access your internal infrastructures via an IPsec VPN server. To use the IPsec VPN server on the present system you should activate it first (use the command mode). Then the vpnipsec command can be used to create and manage IPsec VPNs.
We distinguish two IPsec VPN modes: site to site VPNs and remote access VPNs. A site to site (or inter site) VPN allows you to build a permanent secure tunnel between two sites. With such a tunnel, computers in both sites can communicate with each other in a secure way as they were on the same location whereas in reality they can be separated by several thousands of kilometers. To build a site to site IPsec tunnel you need two VPN servers: a local VPN server and the remote (or peer) VPN server. As IPsec is a standard protocol, you can build a site to site VPN using VPN servers provided by distinct manufacturers/editors.
A remote access VPN is a central VPN server to which remote workers can connect via secure tunnels built on top of the internet. With such tunnels remote workers can access computers protected by the VPN server in a secure way as they were on the same location. To build a remote access IPsec VPN you need a central IPsec VPN server while each remote worker connect the central VPN server using an IPsec VPN client. This system supports native IPsec VPN clients provided by most devices and OS in the market. In case where native VPN clients would not work, alternative third party IPsec VPN clients such as strongSwan® can be used. The vpnipsec command allows you to build site to site as well as remote access IPsec VPNs.
The vpnipsec command allows you to build IPsec VPNs without having extensive knowledge in cryptography and IPsec protocols. However having some basic knowledge on IPsec principals can help to better understand the configuration to set. The IPSEC VPN IN SHORT section below aims to explain IPsec in short. Please note that you should chose between the site mode and the remote accesse mode: if you activate the remote access mode you can no longer use site to site IPsec VPNs. To use site to site IPsec VPNs the remote access mode should be deactivated.
The present system use its external interface to establish IPsec VPN with peers or remote clients. That’s why there is no need to specify the local IP address to set an IPsec VPN on this system. You can set the system’s external network interface and IP address using the commands link and ip.
The first [1] usage form allows you to configure the authentication method used on the local IPsec VPN server. To connect to the local IPsec VPN server, remote peers/clients must then use the authentication method configured with this usage form. Currently three authentication methods are supported: the PSK (Pre Shared Key) method (psk), the SSL certificate based method (tls) and the EAP-TLS (Extensible Authentication Protocol TLS) method (eaptls). To activate the pre shared key method use the keyword psk followed by a word composed by a mix of at least 32 alphabetic, numeric or the dash (-) characters. To automatically generate a strong pre-shared-key you can use the keyword auto. To activate the SSL or EAP-TLS based methods use respectively the keyword tls or eaptls followed by the TLS identifier of the SSL certificate to use (refer to the tls command to import, export or generate SSL certificates). Please note that only one authentication method can be activated at the same time. When using the tls or eaptls authentication methods, remote peers/clients must identify the local IPsec VPN server by using the dn (distinguished name) or fqdn (fully qualified domain name) of the specified SSL certificate. The last argument of this usage form allows you to specify the identifier type that should be used by remote IPsec VPN peers/clients. If no identifier type is specified the distinguished name (dn) is used.
It is important to note that:
• In case where the fqdn based identification is used, remote peers/clients should connect the IPsec VPN server using its fqdn and not its IP address (which is the appliance external IP address). Otherwise, the connection won’t establish.
• The dn to use by remote IPsec VPN peers/clients should be the local SSL certificate subject. You can get the subject of an SSL certificate using the tls command.
• The fqdn to use by remote IPsec VPN peers/clients should be a subject alternative name of the local SSL certificate. This means that when using the fqdn, the local SSL certificate should be a SAN certificate. You can get the subject alternative name of an SSL certificate using the tls command.
The second [2] usage form (vpnipsec access...) allows you to deactivate, activate and configure the remote access mode. To deactivate the remote access mode use the keyword off. To activate the remote access mode use the keyword on followed by optional IPsec settings. A brief description of these settings is given in the IPSEC VPN IN SHORT section below.
The third [3] usage form (vpnipsec access conf...) allows you to automatically generate configuration profiles (or connection scripts) to use on remote IPsec VPN client systems. The generated configuration can be displayed (show keyword), saved (save keyword) on a trusted file server or be sent to an email address. Trusted file servers are defined with the access command. The email account used to send the email is configured using the email command. Supported IPsec VPN client systems are as follows (for each system, a brief description on how to use them is given):
• The strongSwan® App on Android® (android keyword): save the generated profile on a file having the .sswan extension, place it on Web server and then import it into the strongSwan® App from that Web server. Please refer to the strongSwan® App documentation for further information.
• Apple® (MacOS® or iPhone® / iOS®) (use the apple keyword): save the generated profile on a file having the .mobileconfig extension and then import it into the Apple® device. Please refer to the Apple® documentation for further information.
• Microsoft® Windows® (windows keyword): run the generated PowerShell script a Windows® system. With Windows®, the client certificate should be imported separately as a machine certificate into the Windows® system. Please refer to the Windows® documentation for further information.
In case where the runtime authentication method is based on a PSK, the IPsec VPN server address used in the generated configuration is set as follows (in order of priority):
• The first IP address in the NAT public IP address list (see the eleventh [11] usage form below).
• If the HA mode is enabled (see the mode and vrrp commands), the external master VRRP IP address having the highest priority. If no master VRRP IP address is defined, the external backup VRRP IP address having the highest priority.
• If the HA mode is disabled, the appliance external IP address (see the ip command).
In case where the runtime authentication method is based on a certificate (tls or eaptls authentication methods), the IPsec VPN server address used in the generated configuration is set to canonical name (CN) part of the subject in that certificate.
The fourth [4] usage form is used to specify the client side authentication method to use in remote access mode. Allowed authentication methods at the client side are psk, tls and eaptls. When using the psk method , the pre shared key to use at the client side should be the same as the pre shared key at the server side. When using the tls or the eaptls methods, the IKE (or EAP) identifier to use by the client should be the canonical name (CN=) part of the subject specified in its SSL certificate
In remote access mode, when remote clients use the tls or eaptls authentication methods at their side, you have the possibility to limit client accesses to IKE (or EAP) identifiers that are explicitly allowed. The fifth [5] usage form is used at that end. In case where the access list defined with this usage form is empty, all authenticated clients are allowed to connect to the IPsec VPN server. Otherwise, only IKE (or EAP) identifiers that are part of that access list are allowed to connect. Normally, the IKE (or EAP) identifier is the CN part of the client certificate subject. In case where the remote client is a Windows® machine and the used authentication method at its side is tls, the IKE identifier is the complete client certificate subject (and not only its CN part).
The sixth [6] usage form (vpnipsec site...) allows you to create site to site IPsec VPNs. A site to site IPsec VPN is identified by a VPN identifier (<vpn-id>). A <vpn-id> must begin with an alpha character and may contains alpha numeric characters as well as the characters "_" and "-". To establish an IPsec tunnel between two IPsec VPN servers each peer should authenticate the other first. Currently two authentication methods are supported: psk and tls. To add a site to site IPsec VPN use the keyword add followed a VPN identifier (<vpn-id>), the remote VPN server address (<peer-vpn-address> (IP address or network name) and an authentication method required from the remote IPsec peer. In case where the remote VPN server IP is set to 0.0.0.0 (or the keyword any), any authenticated remote VPN server would be allowed to establish a site to site IPsec VPN with the local system. Each authentication method required from a remote peer needs its specific parameters to specify. Those parameters are described below.
In case where the authentication method required from the remote peer is psk, the used pre shared key must be between 32 and 64 characters.
In case where the authentication method required by the peer is based on an SSL certificate (tls authentication method), the SSL certificate advertised by the remote peer should be a SAN certificate and must be trusted by the local system. To trust an SSL certificate, the CA certificate that has been used to sign it should be present on the local system. The remote peer can also advertise a self signed certificate. In this case that SSL certificate should be present as a server certificate on the local system. You can import and trust CA and server SSL certificates using the tls command. The remote peer identification can be either DN (Distinguished Name) based, FQDN (Fully Qualified Domain Name) based or self signed certificate based:
• For a DN based identification, use the dn keyword followed by the distinguished name of the advertised SSL certificate. The distinguished name to use should be the subject part of the SSL certificate. It’s a list of assertions (key = value) separated by a comma (the whole distinguished name should be placed between quotes).
• For an FQDN based identification, use the keyword fqdn followed by the fully qualified domain name of the advertised SSL certificate. The fqdn of an SSL certificate is the last assertion part of its subject and should also be specified as a subject alternative name in the SSL certificate.
• For a self signed certificate based identification, use the certificate keyword followed by the <tls-id> of that self signed certificate. It is important to note that if the identification method required by the remote peer is FQDN, the remote peer address must be specified as network name and not an IP address. In this case, the specified network name should match the FQDN of the self signed certificate. Otherwise, the IPsec tunnel won’t establish.
With the sixth [6] usage form, some optional arguments can be specified. In case where they are not specified default values are used. Default values for optional arguments are given below.
Default values for optional arguments are as follows:
• <ike-encryption used by the remote peer: aes256
• <ike-integrity> used by the remote peer: sha256
• <diffie-hellman> used by the remote peer: modp2048
• <esp-encryption> used by the remote peer: aes256
• <esp-integrity> used by the remote peer: sha256
• <remote-isakmp-port> used by the remote peer: 500
• <remote-nat-transversal-port> used by the remote peer: 4500
The seventh [7] usage form is used to delete a site to site IPsec VPN or completely erase all site to site IPsec VPNs in the system.
With an IPsec VPN a local network can SECURELY communicate with a remote network via an untrusted public network such as the internet. The eighth [8] usage form allows you to specify the local and remote networks to automatically route via the IPsec tunnel. With a site to site IPsec VPN at least one remote network should be specified. In remote access mode if no remote network is specified the default 172.17.0.0/16 network is used. This means that remote workers will get a virtual IP address in the 172.17.0.0/16 network. In all cases, if no local network is specified, the internal connected network (connected to the internal interface (or the web interface in VLAN mode)) is routed via the IPsec tunnel. If no <network-mask> is specified the default network mask 255.255.255.0 is used. To specify the default route you can either use the network "0.0.0.0 0.0.0.0" or the keyword default.
When the routing configuration uses more than one external gateway (connected to the external interface) that source NAT the traffic with their own (distinct) IP addresses, the IPsec VPN configuration requires some tweaks in order to allow the system to properly establish a VPN tunnel. The ninth [9] usage form allows you to explicitly specify (via) gateways to use for a given IPsec VPN. Via gateways can have two roles: the master role and the backup role. During the first IPsec VPN establishment, a master gateway with the highest priority is elected to route IPsec VPN traffic for a given IPsec VPN (specified by its <vpn-id>). The elected gateway is then activated for that IPsec VPN. Please note that at a given point, one and only one gateway is considered as active for a given IPsec VPN. In case of a failure on the active gateway, a backup gateway (with the highest priority) is then elected to be activated. In case where a faulty gateway becomes operational again, the process of electing and activating a new gateway is performed again.
To add a master via gateway to a given site to site IPsec VPN, use the keyword via site followed by the given IPsec VPN identifier (<vpn-id>), the keyword add, the gateway IP address to use, the keyword master and optionally the priority associated to the specified gateway. To add a backup gateway, use the keyword backup instead of the master keyword. To delete a gateway, use the keyword del instead of add. To erase the list of all via gateways for a given IPSec VPN, use the keywords raz. To add or delete gateways in IPsec access mode, replace the couple "site <vpn-id>" by the keyword access. The priority is a numeric value between 0 and 255. If no priority is specified, the priority is set to 110 for a master gateway and to 100 for a backup gateway.
For a site to site IPsec tunnel where the remote IPsec peer is accessible via multiple gateways (with distinct public IP addresses), remote backup IP addresses or network names should be specified on the local system. Otherwise, in case of a failure on the remote master address (IP or network name), the IPsec tunnel can’t be established. The tenth [10] usage form allows you to manage remote backup addresses for a site to site IPsec tunnel. To add a remote backup address to a site to site IPsec tunnel, use the keyword to followed by VPN identifier (<vpn-id>), the keyword add and the remote peer backup address. To delete a remote peer backup address, use the keyword del (instead of the add keyword). To erase the list of all remote peer backup addresses associated to a site to site IPsec tunnel, use the keyword to followed by the VPN identifier (<vpn-id>) and the keyword raz.
In a configuration where the appliance is behind NAT (its external IP address is translated into one or more public IP addresses) and the used authentication method (on the local appliance) is PSK, all public NAT IP addresses should be specified on the local system in order to allow remote active (see below) peers to be properly authenticated. The eleventh [11] usage form allows you to manage those NAT IP addresses. To add a NAT IP address use the keywords nat public add followed by the NAT IP address. To delete a NAT IP address, use the keyword del (instead of the add keyword). To erase the list of all public NAT IP addresses use the keywords nat public raz.
In a site to site IPsec VPN configuration where both local and remote peers are behind NAT, one peer should take the passive role while the other should act as active (the one that initiates first the connection). In a Hub and Spoke architecture, where the central hub and spokes are all behind NAT, the central hub must act as passive while spokes should take the active role. The eleventh [11] usage form allows you to configure the role of remote peers. To configure a remote peer as passive for a site to site IPsec VPN, use the keywords nat role followed by its identifier (<vpn-id>) and the keyword passive (in this case the local peer takes the active role). To configure a remote peer as active for a site to site IPsec VPN, use the keywords nat role followed by its identifier (<vpn-id>) and the keyword activee (in this case the local peer takes the passive role). When configuring such a site to site IPsec VPN, please take care to do not select the same roles for both peers. If no NAT role is specified for a site to site IPsec VPN, the active role is assumed for it. Using the keyword raz allows you to restore the default behaviour for a NAT role.
The twelfth [12] usage form allows you to display a report on the status of configured IPsec VPNs. To display the report use the keyword report.
The vpnipsec command automatically adds required routes for IPsec VPN traffic (and you shouldn’t add them with the ip command). The apply command checks the compatibility of all routes to install and in case of conflicts it refuses to apply the new configuration. When managing routes and networks with the ip and vpnipsec commands please carefully consider the following rules:
• IPsec VPN remote networks and networks in the main routing table (created using the ip command) should be distinct (this is also valid for the default network).
• An IPsec VPN local network can be either the default network, a network connected to the internal or auxiliary interface or a non connected network on condition that a route is manually added (using the ip command) for that network via a gateway connected to the internal or auxiliary interface.
• At least one remote network should be specified for a site to site IPsec VPN.
• An IPsec VPN remote network can’t be a network connected to the internal, external or auxiliary interface.
IPsec VPN remote networks are subject to security policies as follows:
• In case where the internal network is routed in an IPsec tunnel, remote networks can ping the system’s internal network interface (web network interface in vlan mode) via that that tunnel.
• In case where the internal network is routed in an IPsec tunnel, remote networks can potentially access the system’s embedded proxy, transparent proxy, DNS server and the antivirus. Accesses are controlled by the access command (see the the access command for further information).
• In case where no rule is defined in the vpnipsec firewall rule set, all new connections incoming from the vpnipsec zone and destined to the internal zone (the web zone in vlan mode) are allowed (see the the firewall command for further information).
An Ipsec VPN tunnel between two peers is built in two phases: in the phase 1, the two participants negotiate the security mechanisms to use in order to establish the VPN tunnel in the phase 2. Negotiation phases use a protocol called IKE (Internet Key Exchange). Please note that the system supports IKE version 2 only. One of the most important step in the phase 1 is the authentication of a peer by the other. With IKEv2 the two peers can use distinct authentication methods. Currently the system supports three authentication methods: the pre shared key (psk), the X.509 SSL certificate based (tls) and the EAP-TLS (eaptls).
Once the two peers has authenticated each other, they should agree on the encryption algorithm, the integrity algorithm and the strength of the key to use in the DH (Diffie Hellman) key exchange process in phase 1. At the end of the phase 1 the two peers will have a shared key that they can use in phase 2 to securely communicate with each other to agree on the encryption algorithm, the integrity algorithm and the strength of the key to use in the DH key exchange process for future transited data between the two peers. With the present system the DH to use in phase 2 is the same as the DH in phase 1.
The present system supports the following encryption algorithms:
• aes128: 128 bit AES-CBC
• aes192: 192 bit AES-CBC
• aes256: 256 bit AES-CBC
• aes128ctr: 128 bit AES-COUNTER
• aes192ctr: 192 bit AES-COUNTER
• aes256ctr: 256 bit AES-COUNTER
Supported integrrity algorithms are as follows:
• sha1: SHA1 160 160 HMAC
• sha256: SHA2 256 128 HMAC
• sha384: SHA2 384 192 HMAC
• sha512: SHA2 512 256 HMAC
The Diffie-Hellman key-exchange groups that you can use with the present system are as follows:
• Regular Modular Prime Groups:
• modp1536: group 5 (1536 bits)
• modp2048: group 14 (2048 bits)
• modp3072: group 15 (3072 bits)
• modp4096: group 16 (4096 bits)
• modp6144: group 17 (6144 bits)
• modp8192: group 18 (8192 bits)
• NIST Elliptic Curve Groups:
• ecp192: group 25 (192 bits)
• ecp224: group 26 (224 bits)
• ecp256: group 19 (256 bits)
• ecp384: group 20 (384 bits)
• ecp521: group 21 (521 bits)
• Brainpool Elliptic Curve Groups:
• ecp224bp: group 27 (224 bits)
• ecp256bp: group 28 (256 bits)
• ecp384bp: group 29 (384 bits)
• ecp512bp: group 30 (512 bits)
Algorithms are ordered from the weakest to the strongest from the security perspective. Please note that the stronger the algorithm is, the more computation it requires and hence a more powerful CPU.
IKE uses ISAKMP (an UDP protocol) for the key exchange so an IPsec VPN client or peer should know the IPsec VPN server IP address an ISAKMP port to connect to. Because an IPsec VPN server may use a NATed IP address, IPsec packets can be encapsulated in UDP packets. In IKE this is called NAT-Traversal. The default ISAKMP and NAT-Traversal ports are respectively 500 and 4500. In most cases you do not need to modify default ports but because some internet providers may block those ports you have the possibility to modify them. ISAKMP and NAT-Traversal ports for a remote IPsec VPN peer can be set when adding an IPsec VPN while local ISAKMP and NAT-Traversal ports can be modified using the command port.
An IPsec VPN uses the AH (Authentication Header) or the ESP (Encapsulating Security Payload) protocols. AH provides a mechanism for authentication only while ESP provides data encryption in addition. The present system supports the ESP protocol only.
At the time of writing, in remote access mode, the following restrictions are applied regarding Apple® & Android® devices:
• The Android® native IPsec VPN client is not compatible with the present system. To establish IPsec tunnels between Android® devices and the present system we suggest to use an IPsec VPN client such as strongSwan® App (www.strongswan.org).
• To establish IPsec tunnels between Apple® devices and the present system, the authentication method to use can be "psk" or "tls fqdn" (dn identifier based is not supported). Also please note that only SAN certificates are supported with Apple® devices.
• The Windows® native IPsec VPN client supports the tls based authentication method only (psk based authentication authentication is not supported).
access (1) apply (1) domainname (1) email (1) firewall (1) ip (1) link (1) mode (1) port (1) qos (1) system (1) tls (1) vlan (1) vrrp (1)
CacheGuard Technologies Ltd <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2025 CacheGuard - All rights reserved