In phase 2, the data for the IP tunnels is negotiated. If an error occurs here, it is mostly due to incorrect IP addresses for the tunnel. However, there may not be suitable encryption algorithms here either.

Unsuitable IP addresses are logged as follows:

cannot respond to IPsec SA request because no connection is known for 
    192.168.2.0/24===192.168.1.254[CN=server-vpn]...192.168.1.200[CN=client1]

In this case, the client forgot to configure the virtual IP. This can be seen from the fact that no network is specified behind the IP address of the client. Therefore, the client wants to connect to their real IP instead of the virtual IP (which often fails due to NAT).

An attempt to connect to an incorrect virtual IP (in this case 192.168.2.78) would look like this:

cannot respond to IPsec SA request because no connection is known for 
    192.168.2.0/24===192.168.1.254[CN=server-vpn]...
    192.168.1.200[CN=client1]===192.168.2.78/32

If the peer wants to establish a connection without PFS (Perfect Forward Secrecy), but if it is activated on the Intra2net system, it looks like this in the logs:

we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION
sending encrypted notification NO_PROPOSAL_CHOSEN to 192.168.1.200:500

The encryption algorithms must also match in phase 2. If this is not the case (in the example, the client wants to encrypt with simple DES), it looks like this:

IPSec Transform [ESP_DES (64), AUTH_ALGORITHM_HMAC_SHA1] refused due 
    to insecure key_len and enc. alg. not listed in "esp" string
no acceptable Proposal in IPsec SA
sending encrypted notification NO_PROPOSAL_CHOSEN to 192.168.1.200:500

A successful connection setup, on the other hand, is logged as follows:

IPsec SA established