[Swan] Aggressive mode not possible with Juniper Netscreen

[Philippe Vouters]

Dear Elison,

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

I am not equipped with the same equipment as you but I think I shall be 
able with some imagination to answer your remark.

In a first step, I shall observe with Wireshark on both sides, Shrew VPN 
client on one side and Libreswan as a VPN server on the other as well as 
using and trying to understand both Shrew's and Libreswan log files when 
exactly in this configuration the network packets get actually encrypted.

Next, from the certainty of exactly when, I shall dig onto the IPSec 
RFCs to tell you whether both Shrew and Libreswan are actually right to 
behave such way. Note that I shall use aggressive mode to best cope with 
your configuration.

Does the above upcoming attempt and way to proceed to address your 
concern suit you ?
Warmest regards,

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

Le 16/01/2013 10:44, Elison Niven a écrit :
> Hi,
>
> The console of the Juniper gives only some details of the VPN. I have 
> uploaded the Juniper configuration here :
> https://www.dropbox.com/sh/4ugc8xsc05c6hjn/mMxcNuH2ie/Juniper_Config 
> (Please bear with the images !)
>
> 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"
>
> I doubt that it is a configuration error as If I initiate the tunnel 
> from Libreswan, it gets established successfully.
>
> On Thursday 10 January 2013 08:16:33 PM IST, Paul Wouters wrote:
>> On Thu, 10 Jan 2013, Elison Niven wrote:
>>
>>> I am facing this issue with Juniper netscreen :
>>> https://www.openswan.org/issues/1218
>>>
>>> Issue occurs only when Netscreen initiates the tunnel.
>>>
>>> Looking at the tcpdump capture, I see this :
>>> Netscreen ---> Libreswan
>>>
>>> Aggr Mode(unencrypted) --->
>>>     <--- Aggr Mode (unencrypted)
>>> Aggr Mode(unencrypted) ---->
>>>     <--- Informational (Error : We expect encrypted packet)
>>>
>>>
>>> Netscreen is behaving wrongly here.
>>>
>>> I also tried out the same with Netscreen and a Fortinet device.
>>> Interestingly, the same scenario works here.
>>>
>>> Netscreen ---> Fortinet
>>> Aggr Mode(unencrypted) --->
>>>     <--- Aggr Mode (unencrypted)
>>> Aggr Mode(unencrypted) ---->
>>> Quick Mode (encrypted) ---->
>>>     <---- Quick mode (encrypted)
>>> Quick Mode (encrypted)
>>>     <---- Quick mode (encrypted)
>>
>> As I also answered in that bug report, this is usually a configuration
>> issue.
>>
>> Usually when you see "packet should be encrypted" it means one endpoint
>> finished setting up phase1, but on the last confirmation packet the 
>> other
>> end rejects that configuration. Since the other end has no valid crypto,
>> it sends the error in plaintext.
>>
>>> I am wondering how it is possible to establish Phase 1 aggressive
>>> mode when the responder has sent just one packet !
>>
>> The point of aggressive mode is that it takes a full packet exchange
>> less then main mode, so receiving/sending two packets instead of one.
>> It does so at the cost of some privacy (the IDs are sent in the first
>> packet, before DH has been established)
>>
>>> Is there any extension to aggressive mode that Libreswan needs to
>>> incorporate?
>>
>> Most likely, you have a slight misconfiguration between the netscreen
>> and *swan. Verify your DH/modp group, PFS setting, and IKE setting.
>> Specify only 1 ike= proposal, which matches exactly the remote
>> configuration.
>>
>> If you can give us the configurations of netscreen/fortinet for
>> comparison, we can see if your configuration might be mismatched, and
>> confirm there is no bug with *swan.
>>
>> Paul
>> Paul
>>
>>
>
> -- 
> Best Regards,
> Elison Niven
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>