notempty
- Note on the use of ACME certificates
- DPD Timeout and DPD Interval can be configured
Introduction
A Site-to-Site connection links two networks together.
For example, the local network of a main office with the local network of a branch office / secondary office.
Public IP addresses, as well as dynamic DNS entries, can be used to connect the two remote gateways.
Configuration of an IPSec Site-to-Site connection
Setup Wizard
Step 1 - Connection type | |||
Caption | Value | Description | |
---|---|---|---|
Site to Site | The following connections are available.
For the configuration of a Site-to-Site connection, this one is selected. | ||
Step 2 - General | |||
Name: | IPSec S2S | Name for the connection | |
Authentication method: | Also possible: | ||
For authentication method Pre-Shared Key: |
12345 | An arbitrary PSK. The | button generates a very strong key.|
For authentication method X.509 Zertifikat: |
Selection of a certificate This certificate must be created beforehand under . ACME certificates can also be used.
| ||
IKE Version: | Selection of the IKE version New from v12.2 When using IKE v2 it is possible to combine multiple subnets under one SA (default for newly created connections). Without this option, a separate SA is negotiated for each subnet combination. This has significant disadvantages, especially with numerous SAs, and leads to limitations and losses in the stability of the connections due to the design of the IPSec protocol. This option is activated while editing the phase 2 configuration with the entry Group subnet combinations. For authentication method | ||
Step 3 - Local | |||
Local Gateway ID: | LAN1 | Any string The gateway ID flows into the authentication. This can be an IP address, a host name or an interface. On the remote gateway, this value must be configured exactly the same way. |
|
For authentication method Private RSA key: |
Private RSA key for identification | ||
Share networks: | » ✕192.168.122.0/24 | The local network of the remote gateway to be accessed | |
Step 4 - Remote Gateway | |||
Remote Gateway: | 192.0.2.192 | Public IP address (or hostname that can be resolved via DNS) of the remote gateway. | |
Remote Gateway ID: | 192.0.2.192 | ID configured as local ID on the remote gateway (any character string). | |
For authentication method Public RSA key: |
RSA key, the public part of which the remote gateway must use to authenticate itself. | ||
Share networks: | » ✕192.168.192.0/24 | The local network of the remote gateway to be accessed | |
Exit the setup wizard with | |||
To do this, the option Group subnet combinations is activated in phase 2.
notempty
notempty This article refers to a version that is no longer current! notempty The article for the latest version is here There is already a newer version of this article, but it refers to a Reseller-Preview
| |||
Phase 1 | |||
Connections Button GeneralTab General | Tab |||
Caption | Value | Description | |
Allow any remote addresses: | On Default |
Disable this option for site-to-site connections with DynDNS hosts if multiple IPsec connections with a priori unknown addresses (DynDNS S2S, Roadwarrior) are configured. | |
Initiate Connection: | The tunnel is initiated by the UTM even if no packets are sent. Incoming requests are accepted. | ||
The UTM accepts incoming tunnel requests. No outgoing connection is created. | |||
The tunnel is initiated by the UTM only when packets are to be sent. | |||
Deactivates the tunnel | |||
Dead Peer Detection: | On | Checks at a set interval whether the tunnel still exists. If the tunnel was terminated unexpectedly, the SAs are dismantled. (Only then it is also possible to reestablish a new tunnel). | |
DPD Timeout: Only with IKEv1 New as of 12.2.3 |
30 seconds | Period before the state under Startup behavior is restored. The same values are used here as for regular packets. | |
DPD Interval: New as of 12.2.3 |
10 seconds | Testing interval | |
Compression: | Off | Compression is not supported by all remote stations | |
Tab IKE Settings that must be identical in the UTM and in the client: IKE | |||
Caption | Default-Werte UTM | Default-Werte NCP-Client | |
Encryption: | AES 128 Bit | ||
Authentication: | Hash: SHA2 256 Bit | ||
Diffie-Hellman Group: | IKE DH-Grupe: DH2 (modp1024) | ||
Tab IKE More settings: | |||
Caption | Value | Description | |
Strict: | Off | The configured parameters (authentication and encryption algorithms) are preferred for connections | |
On | No further proposals are accepted. A connection is only possible with the configured parameters. | ||
IKE Life time: | Validity period of the Security Association: Agreement between two communicating entities in computer networks. It describes how the two parties apply security services to communicate securely with each other. When using multiple services, multiple security connections must also be established. (Source: Wikipedia 2022) in phase 1 | ||
Rekeying: | Number of attempts to establish the connection (initial or after abort). For E2S connections (Roadwarrior), the setting 3 times can avoid endless attempts to connect to devices that are not correctly logged out. | ||
Phase 2 | |||
Connections Button GeneralTab General : Settings that must be identical in the UTM and in the client: | Tab |||
Caption | Default-Werte UTM | Default-Werte NCP-Client | |
Encryption: | AES 128 Bit | ||
Authentication: | SHA2 256 Bit | ||
DH-Gruppe (PFS): | keine | ||
Schlüssel-Lebensdauer: | Validity period of the key in phase 2 | ||
Austausch-Modus | Main Mode (nicht konfigurierbar) | Aggressive Mode (IKEv1) The UTM does not support Aggressive Mode for security reasons. | |
Tab General: More settings | |||
Caption | Value | Description | |
Restart after abort: | No | If the connection was terminated unexpectedly, activating will restore the state configured under Startup behavior in phase 1. | |
Group subnet combinations: Only with IKEv2 |
Yes |
If more than one network is configured on the local side or at the remote gateway, a separate SA is negotiated for each subnet combination when it is deactivated. This results in numerous subnet combinations and thus many SAs, especially with multiple subnets, and leads to limitations and losses in the stability of the connections due to the design of the IPSec protocol. | |
SubnetsTab Subnets Only with IKEv2 | |||
Scenario: All subnets have access to each other
With an SSH login as root, the behavior can be understood particularly well.
|
|||
Scenario: Not all subnets may access every network of the remote gateway
If in phase two a local network is not connected to all remote networks (or a remote network is not connected to all local ones), this will not be taken into account if the option Group subnet combinations is active! The Group subnet combinations option will connect all local networks to all remote networks!
Port filter rules make it possible to control access.
With an SSH login as root, the behavior can be understood particularly well.
|
|||
TroubleshootingDetailed Troubleshooting instructions can be found in the Troubleshooting Guide If an email address should be used as gateway ID, it is necessary to insert a double @@ in front of the ID (mail@... becomes @@mail@...). Otherwise the ID will be treated as FQDN
| |||
Group subnet combinations: On |
If more than one network is configured on the local side or at the remote gateway, a separate SA is negotiated for each subnet combination when it is deactivated. This results in numerous subnet combinations and thus many SAs, especially with multiple subnets, and leads to limitations and losses in the stability of the connections due to the design of the IPSec protocol. |
||
All subnets have access to each other | With an SSH login as root, the behavior can be understood particularly well.
|
||
Not all subnets may access every network of the remote gateway | If in phase two a local network is not connected to all remote networks (or a remote network is not connected to all local ones), this will not be taken into account if the option Group subnet combinations is active! The Group subnet combinations option will connect all local networks to all remote networks! Port filter rules make it possible to control access. With an SSH login as root, the behavior can be understood particularly well.
|
||
RulebookTo grant access to the internal network, the connection must be allowed. | |||
It is possible, but not recommended to do this with implied rules under VPN to configure this. |
|||
As a general rule: Only what is needed and only for the one who needs it is released! Create network objectA network object must be created for the remote network. If the corresponding authorizations are to be assigned, these can be combined into network groups. | |||
Name: | IPSec-S2S | Name for the IPSec S2S network object | |
Type: | VPN network | Type to be selected | |
Address: | 192.168.192.0/24 | The IP address of the local network of the opposite side, as entered in the Installation Wizard in Step 4 - Remote Gateway in the line Share networks. So in this example the network 192.168.192.0/24. | |
Zone: | Zone to be selected | ||
Groups: | Optional: One or more groups to which the network object belongs. | ||
Port filter rule | |||
Two port filter rules must be created. Menu Tab Add Rule Button |
|||
First rule | |||
Source |
internal-network | Host or network (-pool), which should get access to the internal network | |
Destination |
IPSc network | Destination | |
Service |
benötigter Dienst | Service or service group that is needed | |
NAT Type |
|||
Network object |
|||
Second rule | |||
Source |
IPSc network | Host or network (-pool), which should get access to the internal network | |
Destination |
internal-network | Destination | |
Service |
benötigter Dienst | Service or service group that is needed | |
NAT |
No NAT
|
Configuration of the second gateway
It should be noted that the IKE version is identical on both sides.
Use of a Securepoint UTM
On the remote gateway, the settings must be made in a similar way
- A new IPSec VPN connection is created using the IPSec wizard
- A network object for the IPSec network is created
- Port filter rules are created
Remote Gateway step 2
- The same authentication method must be selected
- The same authentication key (PSK, certificate, RSA key) must be available
- The same IKE version must be used
Remote Gateway step 3
- As Local Gateway ID the Remote Gateway ID from step 4 of the first UTM must now be used
- Under Share Networks the (there remote) network from step 4 of the first UTM must also be used
Remote Gateway step 4
- The public IP address (or a hostname that can be resolved via DNS) of the first UTM must be entered as Remote Gateway.
(This address was not required in the wizard of the first UTM). - The Local Gateway ID from step 3 of the first UTM must be used as Remote Gateway ID
- Under Share networks the (there local) network from step 3 of the first UTM must also be used.
Create network object of the remote gateway
- The network object of the remote gateway represents the network of the first UTM.
Correspondingly, the network address of the local network of the first UTM must be entered under Address.
In the example 192.168.218.0/24
Notes
The transparent HTTP proxy
If a server behind the Site-to-Site connection is to be accessed from the internal network via HTTP, the transparent HTTP proxy may filter the packets.
This can lead to errors while accessing the target.
To prevent this from happening, a rule Exclude must be created in the Tab Transparent mode Button menu with source internal-network to target name-vpn-network-object and protocol HTTP.
Troubeshooting
Detailed Troubleshooting instructions can be found in the Troubleshooting Guide