IPSec Site-to-Site

notempty

Dieser Artikel bezieht sich auf eine nicht mehr aktuelle Version!

notempty

Der Artikel für die neueste Version steht hier

notempty

Zu diesem Artikel gibt es bereits eine neuere Version, die sich allerdings auf eine Reseller-Preview bezieht

IPSec connections Site-to-Site

Last adaption: 12.2

New:

• Ciphers that are no longer considered very secure have been removed
• Subnets combinations possible

notempty

This article refers to a Resellerpreview

11.7 11.6.12

---

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

After logging in to the administration interface of the firewall (in the delivery state: https://192.168.175.1:11115), an IPSec connection can be added in the menu → VPN →IPSec Button Add IPSec connection.

Setup Wizard

Step 1 - Connection type
Caption	Value	Description	Setup step 1
Site to Site	The following connections are available. Roadwarrior Site to Site For the configuration of a Site-to-Site connection, this one is selected.
Step 2 - General
Name:	IPSec S2S	Name for the connection	Setup step 2
Authentication method:	PSK	Also possible: X.509 certificate RSA
For authentication method PSK Pre-Shared Key:	12345	An arbitrary PSK. The button generates a very strong key.
For authentication method X.509 Certificate X.509 Zertifikat:	Server certificate	Selection of a certificate
IKE Version:	IKE v1IKE v2	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 RSA Only IKE v1 is available here.
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. If an email address should be used as Gayteway ID, it is necessary to insert a double @@ in front of the ID (mail@... becomes @@mail@...). Otherwise the ID will be treated as FQDN	Setup step 3
For authentication method RSA Private RSA key:	RSA-Site2Site	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.	Setup step 4
Remote Gateway ID:	192.0.2.192	ID configured as local ID on the remote gateway (any character string).
For authentication method RSA Public RSA key:	RSA-Site2Site	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 Finish
Edit phase 2 New as of v12.2 Combine multiple subnets via MULTI_TRAFFIC_SELECTOR.
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	The wizard automatically connects each local network to each remote network. With an SSH login as root, the behavior can be understood particularly well. Example with two subnets each. Group subnet combinations Enabled root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 192.168.219.0/24 remote: 192.168.192.0/24 192.168.193.0/24 Group subnet combinations Disabled root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.192.0/24 IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.193.0/24 IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.192.0/24 IPSec$20S2S_7: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.193.0/24		All subnets have access to each other
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! This option connects 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. Example with two subnets each. Group subnet combinations Enabled root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 192.168.219.0/24 remote: 192.168.192.0/24 192.168.193.0/24 Group subnet combinations Disabled root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.192.0/24 IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.193.0/24 IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.192.0/24		The second local subnet is connected only to one remote subnet
Rulebook To grant access to the internal network, the connection must be allowed.
It is possible, but not recommended to do this with implied rules under → Firewall →Implied Rules section VPN to configure this. However, these Implied Rules release the ports used for IPSec connections on all interfaces.			Implied rules
As a general rule: Only what is needed and only for the one who needs it is released! Create network object A network object must be created for the remote network. → Firewall →Port FilterTab Network Objects Button Add Object If several subnets exist on the remote gateway, a network object must be created for each subnet. 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	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:	vpn-ipsec	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 → Firewall →PortfilterTab Add Rule Button + If there are different access rights from/to local and remote networks, multiple port filter rules must be setup.		Port filter rules
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	Hidenat Exclude
Network object	external-interface
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

Transparent rule

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 → Applications →HTTP-ProyTab Transparent mode Button Add transparent rule 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