[Swan] Aggressive mode not possible with Juniper Netscreen

Paul Wouters paul at nohats.ca
Thu Jan 10 16:46:33 EET 2013


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


More information about the Swan mailing list