[Swan] Aggressive mode not possible with Juniper Netscreen

Philippe Vouters philippe.vouters at laposte.net
Fri Jan 18 13:57:23 EET 2013


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
>
>



More information about the Swan mailing list