[Swan] Aggressive mode not possible with Juniper Netscreen

Fri Jan 18 15:47:17 EET 2013

Dear Elison,

I checked the Libreswan source code. What I can tell from my source code 
reading is that phase 1 is considered complete at the end of 
aggr_inI2_tail in aggressive mode. As far go the traces you show us, you 
do NOT seem to have reached this point.

It is expected by Libreswan that network packets get encrypted in 
aggressive mode at the beginning of this routine aggr_inR1_outI2_tail 
with the setting of the ISAKMP_FLAG_ENCRYPTION mask flag.

 From this Libreswan trace:
Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: STATE_AGGR_R1: 
sent AR1, expecting AI2
you seem to have passed the point where the ISAKMP_FLAG_ENCRYPTION is set.

As this message:
Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: packet rejected: 
should have been encrypted
comes in an else part of an if (md->hdr.isa_flags & 
ISAKMP_FLAG_ENCRYPTION) (routine process_packet_tail, file 
./programs/pluto/ikev1.c) ,

I can't yet justify reading the source code why you get this message.

After logging this message, the two code lines right after are:
             SEND_NOTIFICATION(INVALID_FLAGS);
which you should retrieve on the Netscreen side, followed by
             return;
the return meaning the network packet is indeed rejected.

In summary, it looks to me there are two issues here :

1/ Libreswan could be wrongly issuing the packet rejected message 
meanwhile taking the corresponding action.
2/ Another problem you seem to face is on your Netscreen side (your 
traces). At the time of the Libreswan packet rejected message, Netscreen 
would wrongly assume it is already phase 2 while Libreswan is still 
keeping in phase 1.

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 18/01/2013 13:16, Elison Niven a écrit :
> Hi,
>
> Here are the logs on Libreswan :
>
> Jan 18 17:35:30 elisonniven pluto[24403]: packet from 10.103.2.75:500: 
> ignoring unknown Vendor ID payload 
> [4a4340b543e02b84c88a8b96a8af9ebe77d9accc0000000b00000500]
> Jan 18 17:35:30 elisonniven pluto[24403]: packet from 10.103.2.75:500: 
> ignoring Vendor ID payload [HeartBeat Notify 386b0100]
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: Aggressive mode 
> peer ID is ID_IPV4_ADDR: '10.103.2.75'
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: responding to 
> Aggressive Mode, state #217, connection "jun" from 10.103.2.75
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: transition from 
> state STATE_AGGR_R0 to state STATE_AGGR_R1
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: STATE_AGGR_R1: 
> sent AR1, expecting AI2
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: packet rejected: 
> should have been encrypted
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: sending 
> notification INVALID_FLAGS to 10.103.2.75:500
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: Quick Mode 
> message is unacceptable because it is for an incomplete ISAKMP SA
> Jan 18 17:35:30 elisonniven pluto[24403]: | payload malformed after IV
> Jan 18 17:35:30 elisonniven pluto[24403]: |   97 69 c4 42  1b 23 88 
> 82  33 20 b4 d3  d7 ec 61 41
> Jan 18 17:35:30 elisonniven pluto[24403]: |   5b ea 8a 1c
> Jan 18 17:35:30 elisonniven pluto[24403]: "jun" #217: sending 
> notification PAYLOAD_MALFORMED to 10.103.2.75:500
> Jan 18 17:35:34 elisonniven pluto[24403]: "jun" #217: Quick Mode 
> message is unacceptable because it is for an incomplete ISAKMP SA
> Jan 18 17:35:34 elisonniven pluto[24403]: | payload malformed after IV
> Jan 18 17:35:34 elisonniven pluto[24403]: |   97 69 c4 42  1b 23 88 
> 82  33 20 b4 d3  d7 ec 61 41
> Jan 18 17:35:34 elisonniven pluto[24403]: |   5b ea 8a 1c
> Jan 18 17:35:34 elisonniven pluto[24403]: "jun" #217: sending 
> notification PAYLOAD_MALFORMED to 10.103.2.75:500
> Jan 18 17:35:38 elisonniven pluto[24403]: "jun" #217: Quick Mode 
> message is unacceptable because it is for an incomplete ISAKMP SA
> Jan 18 17:35:38 elisonniven pluto[24403]: | payload malformed after IV
> Jan 18 17:35:38 elisonniven pluto[24403]: |   97 69 c4 42  1b 23 88 
> 82  33 20 b4 d3  d7 ec 61 41
> Jan 18 17:35:38 elisonniven pluto[24403]: |   5b ea 8a 1c
> Jan 18 17:35:38 elisonniven pluto[24403]: "jun" #217: sending 
> notification PAYLOAD_MALFORMED to 10.103.2.75:500
>
> The pcap file for the same logs above is at 
> https://dl.dropbox.com/u/60175032/Juniper_To_Libreswan.pcap
> Thanks !
>
> On Friday 18 January 2013 05:27:23 PM IST, Philippe Vouters wrote:
>> Dear Elison,
>>
>> Had a look at this RFC at
>> http://www.shrew.net/static/help-2.1.x/vpnhelp.htm?IPSecurity.html
>> that I carefully read.
>> It specifically says the following:
>> <QUOTE>
>>
>> If the client from behind the NAT initiates
>>    security, his connection will be secured.  If he sends in the clear,
>>    the server will still accept that clear text.
>>
>> </QUOTE>
>> As far as I can guess the real problem with the above quoted assertion
>> in mind, Libreswan ought to be incorrectly rejecting an unencrypted
>> packet while the connection has been not been initiated with security.
>>
>> However from your Netscreen traces and previous mails, it does look
>> like Netscreen and Libreswan disagree onto when to actually initiate
>> with security and encrypt at the correct moment and on both sides the
>> network packets.
>>
>> To best understand the situation, can you send us the Libreswan log
>> file extract which occurs at 2013-01-18 21:19:38 on the Libreswan side
>> of the network dialog. You have to look in Libreswan log file at when
>> it recognizes that phase 2 has started. With the two timed traces in
>> parallel on each side, this becomes more meaningful.
>>
>> I do not know how I can reproduce your problem and have a deeper look
>> into. To make things clear between you and us, a question to you: is
>> your network configuration NAT'ed or can be considered completely
>> behind a NAT ?
>>
>> I let also Paul give his point of view onto in case I misinterpreted
>> something.
>>
>> Philippe Vouters (Fontainebleau/France)
>> URL: http://vouters.dyndns.org/
>> SIP: sip:Vouters at sip.linphone.org
>>
>> Le 18/01/2013 10:41, Elison Niven a écrit :
>>>
>>> On Wednesday 16 January 2013 10:17:12 PM IST, Paul Wouters wrote:
>>>>
>>>> It seems to match the screen shot configuration apart from that I 
>>>> don't
>>>> see the compress= option or the pfs= option. I recommend setting
>>>> compress
>>>> to "no". compression can cause weirdness where it works if you
>>>> respond, but not
>>>> when you initiate, due to the extra flexability on the *swan side for
>>>> this. If that still fails, try to _also_ set pfs=no.
>>>
>>> I tried with compress=no and then also with pfs=no.
>>> No difference. Still get the same error.
>>>
>>>>>> I doubt that it is a configuration error as If I initiate the tunnel
>>>>>> from Libreswan, it gets established successfully.
>>>>
>>>> Which seems to be the reverse of the compress= issue...
>>>>
>>>> Do you have any logs of the netscreen?
>>>
>>> Read from bottom to top, Netscreen says it is done with Phase 1.
>>>
>>> 2013-01-18 21:19:42    info    Rejected an IKE packet on untrust from
>>> 10.103.2.75:500 to 10.103.6.114:500 with cookies ca2acb1d14ef4d95 and
>>> faac2e39e076cef3 because an unencrypted packet unexpectedly arrived.
>>> 2013-01-18 21:19:38    info    Rejected an IKE packet on untrust from
>>> 10.103.2.75:500 to 10.103.6.114:500 with cookies ca2acb1d14ef4d95 and
>>> faac2e39e076cef3 because an unencrypted packet unexpectedly arrived.
>>> 2013-01-18 21:19:38    info    Rejected an IKE packet on untrust from
>>> 10.103.2.75:500 to 10.103.6.114:500 with cookies ca2acb1d14ef4d95 and
>>> faac2e39e076cef3 because an unencrypted packet unexpectedly arrived.
>>> 2013-01-18 21:19:38    info    IKE<10.103.6.114> Phase 2: Initiated
>>> negotiations.
>>> 2013-01-18 21:19:38    info    IKE<10.103.6.114> Phase 1: Completed
>>> Aggressive mode negotiations with a <28800>-second lifetime.
>>> 2013-01-18 21:19:38    info    IKE<10.103.2.75> >> <10.103.6.114>
>>> Phase 1: Initiated negotiations in aggressive mode.
>>>
>>> Any ideas on how I can make this work?
>>>
>>> -- 
>>> Best Regards,
>>> Elison Niven
>>>
>>>
>>
>>
>>
>
> -- 
> Best Regards,
> Elison Niven
>
>