[Vpn-help] Connection ends up in phase2 not found

[mgrooms]

On Tue, 6 Nov 2007 23:21:06 +0100, "Marko Schmalenbach" <marko at yavanna.net>
wrote:
> I am no expert at this VPN stuff. My connection always ends up in "phase2
> not found".
> Can anybody tell me what this exactly means?
> 
> ii : phase1 sa established
> ii : 213.172.110.68:500 <-> 192.168.1.12:500
> ii : 3c3d05fb5213dae2:b7b0262afe8f7d1
> DB : phase1 ref decrement ( ref count = 1, phase1 count = 1 )
> ii : sending peer INITIAL-CONTACT notification
> ii : - 192.168.1.12:500 -> 213.172.110.68:500
> ii : - isakmp spi = 3c3d05fb5213dae2:b7b0262a0fe8f7d1
> ii : - data size 0
>>> : hash payload
>>> : notification payload
> == : new informational hash ( 16 bytes )
> == : new phase2 iv ( 8 bytes )
>>= : encrypt iv ( 8 bytes )
> => : encrypt packet ( 76 bytes )
> == : stored iv ( 8 bytes )
> -> : send IKE packet 192.168.1.12:500 -> 213.172.110.68:500 ( 104 bytes )
> DB : config ref increment ( ref count = 1, config count = 0 )
> DB : tunnel ref increment ( ref count = 3, tunnel count = 1 )
> DB : config added
> ii : xauth is not required
> DB : config ref decrement ( ref count = 0, config count = 1 )
> DB : phase1 ref increment ( ref count = 2, phase1 count = 1 )
> DB : phase1 ref increment ( ref count = 3, phase1 count = 1 )
> DB : phase2 not found
> 

Marko,

This seems to have been a source of misunderstanding so let me take this
opportunity to explain. The "DB : phase2 not found" message is very normal
in this instance. It gets spit out whenever the DB routine that searches
for a phase2 handle based on a given criteria is not found. You see, an IKE
daemon receives an ACQUIRE request from the IPSEC layer when a phase2
security association needs to be negotiated for a given policy. But a
phase1 security association must exist before phase2 processing can ensue
so sometimes a handle will get created in a PENDING state. In the instance
you have discovered, the IKE daemon is searching for any pended phase2
handles that it might be able to process using the newly established phase1
security association. The connection was only just established so naturally
it doesn't have any pended phase2 handles to process. This yields a "DB :
phase2 not found" message :)

Do you happen to be connecting with a Open/FreeSWAN gateway? From what I
gather, there is a disparity between the way Open/FreeSWAN tunnels
typically operate and the way the rest of the IPsec world operates. That is
Open/FreeSWAN tunnels will establish phase2 ( IPsec SAs ) before any
traffic actually matches a security policy. The Shrew Soft Client will not
attempt to negotiate phase2 until it receives an AQUIRE message from the
IPsec layer. Have you tried pinging a host on the distant network? If you
have the client policies configured correctly, a phase2 negotiation should
at lease be attempted. If it does not complete, your phase2 parameters are
likely mismatched which will produce different output than you see above.

Thanks for trying out the Shrew Soft Client. Please let me know if I can be
of further assistance.

-Matthew