In Phase 2 werden die Daten für die IP-Tunnel ausgehandelt. Tritt hier ein Fehler auf, so sind meistens falsche IP-Adressen für den Tunnel hinterlegt. Allerdings kann es auch hier nicht passende Verschlüsselungsalgorithmen geben.

Nicht passende IP-Adressen werden wie folgt protokolliert:

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 diesem Fall wurde beim Client vergessen, die virtuelle IP zu konfigurieren. Das kann man daran erkennen, dass hinter der IP des Clients kein Netz mehr angegeben ist. Daher möchte der Client eine Verbindung mit seiner realen IP statt mit der virtuellen aufbauen (was häufig wegen NAT fehlschlägt).

Ein Verbindungsversuch mit einer falschen virtuellen IP (hier 192.168.2.78) sähe dagegen so aus:

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

Möchte die Gegenstelle eine Verbindung ohne PFS (Perfect Forward Secrecy) aufbauen, auf dem Intra2net System ist es aber aktiviert, sieht das in den Logs so aus:

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

Auch in Phase 2 müssen die Verschlüsselungsalgorithmen zusammenpassen. Tun sie dies nicht (im Beispiel möchte der Client mit einfachem DES verschlüsseln), sieht dies wie folgt aus:

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

Ein erfolgreicher Verbindungsaufbau wird dagegen so protokolliert:

IPsec SA established