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 [site [add <vpn-id> <peer-vpn-ip> (psk <pre-shared-key> | (tls | eaptls) (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>]]]]]]]]]
[4] vpnipsec [site [raz | del <vpn-id>]]
[5] vpnipsec [network [(access | site <vpn-id>) [(raz | ((add | del) (local | remote) <network-ip> [<network-mask>]))]]]
[6] vpnipsec [via [(access | site <vpn-id>) [raz | (add | del) <gateway-ip> (master backup) [<priority>]]]]
[7] vpnipsec [to [<vpn-id> [raz | (add | del) <peer-vpn-ip>]]]
[8] vpnipsec [nat (public [raz | (add | del) <local-public-ip>]) | (role [<vpn-id> [(active | passive | raz)]])]
[9] 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 VPN 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 of this command allows you to configure the authentication on the local IPsec VPN server. To connect to the local IPsec VPN server, remote IPsec VPN peers or clients will have to use this authentication configuration. Currently three authentication methods are supported: the 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 certificate based method use the keyword tls followed by a TLS identifier. To activate the EAP-TLS method use the keyword eaptls followed by a TLS identifier (see the command tls to import, export or generate SSL certificates). Please note that currently only one authentication method can be activated at the same time. When using the tls or eaptls authentication methods, remote IPsec VPN peers or clients can 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 or clients. If no identifier type is specified the distinguished name is used. It is important to note that:
• The dn to use by remote IPsec VPN peers or clients should be the subject of the local SSL certificate (you can identify the subject of the local SSL certificate by printing the local SSL certificate using the tls command).
• The fqdn to use by remote IPsec VPN peers or 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 identify the subject alternative name of the local SSL certificate by printing the local SSL certificate using the tls command).
The second [2] usage form of this command (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 of this command (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 VPN tunnel between two IPsec VPN servers each peer should authenticate the other first. Currently three authentication methods are supported: psk, tls and eaptls. To add a site to site IPsec VPN use the keyword add followed a VPN identifier (<vpn-id>), the remote VPN server IP address (<peer-vpn-ip>) and an authentication method to require 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 this system. Other parameters are optional. In case where they are not specified default values are used. Default values for optional arguments are given below.
In case where the authentication method to require from the remote peer is psk, the used pre shared key must be between 32 and 64 characters. In case where the authentication method to require from the peer is tls or eaptls, three possibilities are offered to trust the SSL certificate presented by the remote peer for the authentication:
• Specifying the TLS identifier of the presented SSL certificate if the SSL certificate is present in the local system. In this case use the keyword certificate followed by a <tls-id>.
• Specifying the distinguished name (the subject) of the presented SSL certificate if the CA certificate used to sign that SSL certificate is present in the local system. In this case use the keyword dn followed by a distinguished name between quotes.
• Specifying the fully qualified domain name (a subject alternative name) of the presented SSL certificate if the CA certificate used to sign that certificate is present in the local system. In this case use the keyword fqdn followed by a fully qualified domain name.
In all cases you can import and trust SSL certificate and CA certificate using the command tls.
Default values for optional arguments are as follows:
• <ike-encryption: aes256
• <ike-integrity>: sha256
• <diffie-hellman>: modp2048
• <esp-encryption>: aes256
• <esp-integrity>: sha256
• <remote-isakmp-port>: 500
• <remote-nat-transversal-port>: 4500
The fourth [4] usage form of this command 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 fifth [5] usage form of this command allows you to specify the local and remote networks to automatically route via the IPsec VPN 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) is routed via the IPsec VPN 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 sixth [6] 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 VPN where the remote IPsec peer is accessible via multiple gateways (with distinct public IP addresses), remote backup IP addresses should be specified on the local system. Otherwise, in case of a failure on the remote master IP, the IPsec tunnel can’t be established. The seventh [7] usage form allows you to manage remote backup IP addresses for a site to site IPsec VPN. To add a remote backup IP address to a site to site IPsec VPN, use the keyword to followed by VPN identifier (<vpn-id>), the keyword add and the remote peer backup IP address. To delete a remote peer backup IP address, use the keyword del (instead of the add keyword). To erase the list of all remote peer backup IP addresses associated to a site to site IPsec VPN, use the keyword to followed by the VPN identifier (<vpn-id>) and the keywordraz.
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 eighth [8] 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 eight [8] 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 ninth [9] 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 VPN 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 VPN 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 client is not compatible with the present system. To establish IPsec VPN tunnels between Android™ devices and the present system we suggest to use an IPsec VPN client such as StrongSwan (www.strongswan.org).
• To establish IPsec VPN tunnels between Apple™ devices and the present system, the authentication method to use on the present system and Apple™ devices should be SSL certificate and fqdn identifier based. Please note that in this case only SAN certificates are supported.
access (1) access (1) apply (1) firewall (1) ip (1) link (1) mode (1) port (1) qos (1) system (1) tls (1) vlan (1)
CacheGuard Technologies Ltd <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2024 CacheGuard - All rights reserved