<div dir="ltr">I am running some tests with Strongswan 5.1.2 and a Juniper SRX 100 firewall, in a site-to-site configuration using IKEv1. The juniper is the initiator of the tunnel. I see a problem with setting up phase 2 connections when the firewall is expiring phase 2s.<div>
<br></div><div>The sequence of messages that flows is</div><div>Initiator (Juniper SRX)                        Responder (Strongswan 5.1.2)</div><div>Quick Mode (1)                  --></div><div>                                        <--           Quick Mode (2)</div>
<div>Informational Msg (D-1)       --></div><div>Informational Msg (D-2)       --><br></div><div>Quick Mode (3)                  --></div><div><br></div><div><br></div><div>The two informational messages D-1 and D-2 are delete messages for the two SAs the FW is expiring.</div>
<div><br></div><div>This sequence of messages causes the quick mode task to get into a weird state. This is how it happens.</div><div>1. When the first quick message is received, the quick mode task (quick_mode_t in src/libcharon/sa/ikev1/tasks/quick_mode.c)  is in QM_INIT state.</div>
<div>2. When the response is sent back to the initiator, the quick_mode task is now in QM_NEGOTIATED state, needing more to complete the phase 2 setup.</div><div>3. When the Informational Msg (D-1) is received, task_manager_v1 goes through its set of passive tasks and gives them this message.</div>
<div>4. One of the passive tasks is the quick mode task that is waiting for the third message in the quick mode handshake. When this task receives the informational message, it is in QM_NEGOTIATED state. There is a check in  process_r function of this task that causes it to return SUCCESS when a INFORMATIONAL_V1 message is received in QM_NEGOTIATED state.</div>
<div>5. When quick_mode_t::process_r returns with a SUCCESS, task_manager_v1  removes the task from its list and destroys it. </div><div>6. When Quick Mode (3) finally arrives, it is given to a new quick mode task, that is now in QM_INIT state. This task now fails because the quick mode task expects an SA payload in the message and Quick Mode (3)  only has the HASH.</div>
<div>7. At this point the phase 2 connection that was being setup is dead and the initiator and responder are out of sync.</div><div><br></div><div><br></div><div>I made a small fix and tried it out. It seems to work for me now.  The fix was to return NOT_SUPPORTED in quick_mode_t::process_r when a INFORMATIONAL_V1 message is received in QM_NEGOTIATED state. In process_request in src/libcharon/sa/ikev1/task_manager_v1.c, when a task returns NOT_SUPPORTED, i continue to the next task in the enumeration (without sending a response). I could not find an appropriate return code to use instead of NOT_SUPPORTED.</div>
<div><br></div><div>This seems to work for me. I want to know if this would be a valid fix for the situation. Without this fix, the tunnel between the SRX and strongswan is unusable after the first rekey.</div><div><br></div>
<div>regards,</div><div>smk</div><div><br></div><div><br></div><div><br></div><div><br></div></div>