[Swan] Aggressive mode not possible with Juniper Netscreen
Philippe Vouters
philippe.vouters at laposte.net
Sat Jan 19 00:45:07 EET 2013
Dear Elison,
To be certain that Libreswan actually considers phase 1 over when
exchanging packets with Netscreen, set plutodebug=control. You should
then read in your log file tracing pluto activity the string:
"phase 1 complete"
Yours truly,
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org
Le 18/01/2013 14:47, Philippe Vouters a écrit :
> 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
>>
>>
>
More information about the Swan
mailing list