[vpn-devel] Linux: unable to locate inbound policy for init phase2

[Matthew Grooms]

On 9/9/2010 5:27 PM, Michael Kenny wrote:
> Mathew -
>
> I pulled down the latest 2.1.7 branch and I think they're different
> problems.
> However, I had a chance to dig into it a little more and came up with
> something that appears to have solved my problem.
>
> In iked/ike.policy.cpp around line 641, I made the following change:
>
>      if( ( type == IPSEC_POLICY_IPSEC ) && ( tunnel->tstate &
> TSTATE_POLICY_INIT ) )
>      {
>          tunnel->tstate &= ~TSTATE_POLICY_INIT;
>          policy->initial = true;
>      }
>
> This prevents phase 2 initialization until an IPSEC policy is installed.
> It then finds the policy it needs for phase 2 and finishes the tunnel.
>
> Another possibility would be to reset the TSTATE_POLICY_INIT bit on the
> tunnel if phase 2 doesn't find the policy it needs?
>

Hi Michael,

The reason I thought you were bumping into an issue that had been 
corrected in 2.1.7 was this output ...

10/08/06 13:52:57 K< : recv pfkey X_SPDADD UNSPEC message
10/08/06 13:52:57 ii : - id   = 80
10/08/06 13:52:57 ii : - type = NONE
10/08/06 13:52:57 ii : - dir  = INBOUND
10/08/06 13:52:57 ii : - src  = them:0/32
10/08/06 13:52:57 ii : - dst  = me:0/32

The fix I was referring to caused the 0/32 network to be used, which in 
turn caused communication failures. These failures were reported on the 
vpn-help mailing list and were reported to be resolved by upgrading to 
the 2.1.7 version ( which I need to release very soon ).

As for the TSTATE_POLICY_INIT issue, I realized that this problem could 
occur in 2.1.x early on in the development process. Its been a while 
since I looked at this code, but I recall the issue being that the 
policy may not have been installed yet when this code gets executed. I 
believe I corrected this in 2.2.x by moving this functionality into the 
policy code so it doesn't try the phase2 init until the policy creation 
response was received from the PF_KEY layer. I'll try to look closer and 
see what can be done to solve the issue. Maybe a new tunnel event would 
work.

-Matthew