[Swan] Aggressive mode not possible with Juniper Netscreen

[Paul Wouters]

On Wed, 16 Jan 2013, Philippe Vouters wrote:

> All your question and the related problem seem to lie into this question : 
> "When *should* a network packet in a VPN dialog be actually encrypted so that 
> the VPN can establish ?" From your tests and what you want to demonstrate us, 
> Libreswan (as a VPN server ?) should be too early responding "packet should 
> be encrypted".

"packet should be encrypted" is really a mismatch of configuration
parameters. The responder rejects the proposal on R2, but by that time the
initiator already believes crypto should be fully up. So the responder
sends an INFORMATIONAL about its configuration mismatch, which is not
encrypted, and the logging message appears. The problem is not that
the packet should be encrypted, but that the IKE negotiation failed to
establish an IKE SA.

>> My libreswan config is :
>> conn jun
>>     leftsubnet=12.12.12.0/255.255.255.0
>>     rightsubnet=192.168.1.0/255.255.255.0
>>     auto=add
>>     left=10.103.6.114
>>     right=10.103.2.75
>>     x_rightdynamic=yes
>>     authby=secret
>>     rekey=yes
>>     rekeyfuzz=100%
>>     keyingtries=3
>>     compress=yes
>>     dpddelay=30
>>     dpdtimeout=120
>>     dpdaction=clear
>>     pfs=yes
>>     aggrmode=yes
>>     ike="3des-sha1-modp1024"
>>     esp="3des-sha1"

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

Paul