First of all, you must ensure that each side has its own key and the public key of the other. It is recommended that you create a dedicated key for VPNs only on each system.
If you set up multiple VPNs on the Intra2net system, you do not have to create a separate key for each connection: You can use a single key for all VPNs. Of course you will still need the public key from each of the peers.
For more details on key management, see 44. Chapter, „Key Management“ and Section 46.2, „Preparing the configuration on the Intra2net system“.
You can configure VPN connections in the Services > VPN > Connections menu. Create a new connection and select the type "".
On the first page, you configure the remote site. The remote site is the official external IP address that the Intra2net system uses to reach the IPSec gateway on the other end of the connection. Do not confuse this with the IP address that the remote site has within its own local network (typically from a private network range).
If the other party has a static IP address, you can either enter that IP address directly or set up a DNS hostname within the customer’s domain and use that instead. The advantage of the DNS hostname is that it can be easily updated centrally to a new IP address if there are changes to the internet connection, whereas the IP address would have to be updated manually on all remote devices.
If the remote system cannot be reached directly from the Intra2net system, for example because it is located behind the local Internet service provider's NAT router, you can select "Dynamic IP (road warrior)" as the type. However, the connection can then only be established from the remote system.
The encryption profile allows you to select the encryption algorithms to be used; for details, see Section 43.8, „Algorithms“.
Encapsulation controls how the packets for the VPN tunnel are packed. With ESP, encryption and authentication are encapsulated. With ESP+AH, encryption and authentication are carried out separately. ESP+AH cannot be conducted through NAT, so ESP is widely accepted. This setting must be identical on both sides of the connection.
Also note the setting for "". Check whether the remote system supports IKEv2, and then select the recommended IKEv2. Otherwise, use IKEv1. This setting must be configured identically on both sides, and the selected encryption profile must match the IKE version.
Select your own key and the key of the remote side.
Authentication using a key or certificate is strongly recommended due to its higher level of security.
If the other party insists on using a pre-shared key (PSK), you must select the IKE IDs for both parties in addition to the shared key. See Section 43.4, „IKE IDs“ for details. It is strongly recommended that you always use the ID_RFC822_ADDR / Email type. The “@” character in the ID makes the type unambiguous. Furthermore, there is no way to associate these IDs with the IP address of the underlying connection, which could lead to misinterpretation.
When using a pre-shared key, it should be generated by a random number generator and be at least 32 full bytes long. To do this, you can use the "" button in the interface, for example. If you use ASCII-encoded characters instead of full bytes, the key should be correspondingly longer. Each connection should use its own unique pre-shared key.
To protect against attacks using quantum computers, the "" feature should be used. This feature is only available with IKEv2. See Section 43.9.1, „Post-Quantum Pre-Shared Key (PPK)“ for details. This function must be configured identically on both sides of the connection.
On the "Tunnel" page, you can configure which networks are connected to each other by this VPN connection.
The "" option selects the network to be connected on the side of the Intra2net system. With the "" option, select one of the networks directly connected or routed to the Intra2net system.
For "" select the "" type and enter IP and netmask of the network behind the IPSec Gateway on the peer's side.
The options for address conversion (NAT) are explained in 53. Chapter, „Solving IP Address Conflicts in VPNs Through NAT“.
In this menu the rights of the VPN network on the peer's side are defined. This applies to all packets coming from the VPN network. A description of the rights options can be found under Section 8.3, „Access Rights of a Network Object“.
This menu is used to configure when the connection is established and when existing sessions are to be extended.
For passive or manual start, the Intra2net system waits until either the peer establishes the connection or a user establishes the connection manually through the mainpage. If the connection is always running, the Intra2net system will continuously try to establish the connection and keep it open.
The number of setup attempts only affects the manual setup on the mainpage. This option has no impact when used in conjunction with "".
The lifetimes for the two phases, or SA variants, in IKEv2 specify the number of minutes after which a connection is re-authenticated and new session keys are negotiated. The time for Phase 1 / IKE_SA should be longer than that for Phase 2 / CHILD_SA. These values do not need to match the settings on the other end.
If a value is entered for "", the Intra2net system sends a packet to the other end at least as often as specified. If no response is received multiple times, the connection is terminated and reestablished. This function uses the Dead Peer Detection (DPD) feature of the IKE standard.
The MOBIKE feature allows the other party to change their external IP address while the system is running. This is particularly relevant for VPN clients.
In most cases, it is recommended to leave the "" option disabled for network-to-network connections, i.e., to use rekeying. This is because, depending on the IKE implementation on the other side, the regular reauthentication process may cause a brief connection interruption. See Section 43.7.3.3, „Re-authentication vs. Rekeying“ for details.